Supports MySQL, PostgreSQL, MongoDB, Microsoft SQL Server, AWS Redshift, Google BigQuery, Druid, H2, SQLite, Oracle, Crate, Google Analytics, Vertica.
Supports MySQL, PostgreSQL, MongoDB, Microsoft SQL Server, AWS Redshift, Google BigQuery, Druid, H2, SQLite, Oracle, Crate, Google Analytics, Vertica.
From their own blog: http://www.metabase.com/blog/Joins
"So rather than spending time constructing complicated queries with a bunch of joins, create SQL Views instead."
No thanks. While I can write manual queries to join... and even make SQL Views... try selling it to the non-developers in the company. The entire point of a BI tool is to eliminate myself as a bottleneck.
Perhaps things have changed by now, I don't know.
...
And to get it out of the way: the same applies for Airbnb's Superset. It's cool and has a lot of different chart types, but 1) really hard to install and 2) data exploration is still hard.
The point with 'insights' is that you can explore the data.
Take this view:
http://insights-demo.mariusandra.com/explorer?columns=Order....
(long URL instead of a shortlink as those are cleared when I reset the demo database)
With no coding time I got a view showing orders by date by country. Now if I click on the rightmost field ("count id"), I can drill deeper and see the orders by the day/country right there. I can use it to investigate anomalies in data.
Right now you must click the data in the column, but very soon it'll be possible to just click it on the graph as well.
This is the niche insights fills and why Metabase and Superset weren't good enough.
We also allow you to group by and filter by "joined" columns across foreign keys. We just never put the word "join" in front of end users. As far as users go, they just know that a transaction has a user and that they can filter by the user's country.
Regarding views vs joins, imo the entire point of doing SQL views (i.e. doing joins or transforms to create wide denormalized tables) is so that end users get a clean, explorable dataset they can understand. If you are dependent on doing 3-way joins in the BI tool then only people that know how to put together 3-way joins will use it.
What we've seen this over and over in companies that use Looker and move to us is that because only analysts or engineers can write LookML, every small modification goes through an engineer or analyst. With Metabase, for the most part, once you spend a bit of time cleaning up the data they see, people just figure things out on their own.
(blatant self promotion from a Metabase team member)
How is this a sustainable product/company? (AKA How do you make money?)
Is love to dig in to what looks like an awesome product. But to justify the time investment, it would be helpful to know how it will be around long term.
(another person from Metabase)