Don't agree, in the past metabase was good, now it's just getting worse.
I was a big fan of metabase (to the point I deployed it in 4 companies and rolled it out for many people to use in their daily workflow). All was nice.
Somewhere around 0.31 something changed in the internal dev/release flow. I get the feeling they have some kind of internal push to add unnecessary untested features which all look nice on paper, and work on a 5-row 5-column user tables. Until you actually use those features and all functionality fails miserably..
Had weird issues with it, which usually occurred after upgrades, on both small and bigger decently indexed DB's (pg and mysql), things like:
- had sets of reports which all worked fine until they hit a 1001 rows.. and suddenly the UI had a react race condition.
- X-Rays which silently fail and break the UI, while on the DB server you see the queries complete.
- Deployed new versions which would hammer databases by distincting every column individually every hour, instead of handling statistics a bit more intelligently. Disabled that ofcourse.
- Deployed versions in other countries, where the UI client-server latency caused the whole UI to break (probably the limits of setTimeout reached? :-)).
If you check the github issues, it's just ignored problems and they are focus on releasing new functionality instead of fixing the issues. Doesn't really motivate to report anymore problems.
They had one good thing: they would allow you to work in sql and write efficient queries, but clearly they decided it's time to remove the last good feature and now only want graphical query builders.
If you use metabase: deploy it on a replica such it doesn't whack your prod DB. And take backups before upgrading, because there is no revert.
I've spent enough time on Metabase problems, won't touch it anymore.
We've walked a fine line between fixing bugs, adding the features that our users have asked for and building out the BI interface we think the world should be using in 5 years.
We don't always get it right, and I'm sorry if we broke things for you on the performance side.
We will be spending a few of our development cycles after 0.33 to try to clear out our bug queue.
One specific factual point I'd like to reply to however -
SQL isn't going anywhere. If anything we're making it easier to both write plain SQL, use SQL templates or use our graphical interface on top of SQL query results in our next release (preview at https://github.com/metabase/metabase/releases/tag/v0.33.0-pr...)
I’ve been using Metabase off and on in prod since 2016. I think you guys are really onto something and I love seeing Clojure in a popular OSS project. I know you guys just got some money; here’s my pitch to make it count: Metabase would be a lot more sticky if you provided a robust home for annotation and discussion. You’re better than most at letting admins describe data, but often users want to talk about the data they are discovering. Doing so in the context of the data is so much more effective than talking about it in generalities in Slack. I think Yellowfin has some features around discussion but there is always room for improvement. Maybe one could: Comment on a data point, write an explanation for why a date range has weird data, or tag a colleague to ask about an outlier in their dept. Celebrate wins with emojis? All I know is that there is nothing stickier or more engaging than discussion history. Keep up the good fight!
While I have you here...
<nag>
bump for the Athena driver. Also I can’t use Metabot without some privacy settings. Can’t anything be done? </nag>
Depends heavily on your use case, but there are a lot of advanced features.
From a review last year (so some of this may be outdated):
- Broader datasource support - 20 sources in Superset, vs 12 in Metabase
Superset supports:
- view creation by users ('create table as'), as well as materialization
- geo/GIS based visualizations
- day over day, week over week, etc. charting; moving averages, etc.
Superset is missing data catalog-like functions, which metabase has, though I didn't evaluate metabase's data catalog in depth. It also requires you to write SQL, where Metabase includes a query builder UI - though there was a rather strange difference in capabilities within Metabase between the SQL-based charting and the query builder UI.
I’ve taken a quick glance and looked at the code. It’s a Java/Spring Boot project which usually gets a lot of flak around here for “too much magic”.
This project is written in a very clean style and seems to use a minimum of Spring. Mainly rest controllers, configuration and and dependency injection. No hibernate/orm or AOP stuff.
This seems to be listed as a feature, which I find confusing. Not everything lives in SQL databases. Some things you extract for example from external APIs.
Is this basically "this is out of scope for the project", or it's a feature because we've got <alternative>?
It's a pity they use pie charts to show off their software. At least the don't show them in 3D. (And just to make it clear: there is no use case where pie charts are the best solution. At best they are an acceptable solution.)
Even worse is the "Sales Ranking" in the first example, clearly the size or area of the entries is not proportional to the differences in sales, instead it is highly misleading to display the data as a perfect triangle. The TreeMap-esque "Qty by Product" is also useless -- is Cup larger or smaller than Glass? Stacked bars for "Location by Year" is another obfuscated mechanism for delivering "information" -- which was the best year for Warehouse?
Use bars showing percentage. This way you can compare the values to a scale on the side and to each other. You can't see a difference easily on a pie chart without annotation. With enough values, you likely can't tell 5% from 10%, and difference between a fragment on the left from a fragment on the right.
This is even worse in 3d pie chart which doesn't even preserve proportions in areas/angles, so splitting in 4 parts, bottom/top will be larger than left/right.
Pie charts are not about the raw numbers, they are about quickly and roughly showing who ate how much of the pizza. In many pie charts, 5% and 10% looking similar is a benefit, not a problem (because in many cases 5/10% are effectively the same - minor but non-negligible portions). Bar charts are not a great option for this.
I think it's better to say that "for most people there is a better alternative" than to say that pie charts should never be used.
EDIT: If you are showing who ate which parts of a pizza (to be pedantic) I'm sure a pie chart may be the best case solution. My favourite use of pie charts is to compare the harmonic series and the series 1/x^2, but then again this latter example is not really a traditional pie chart.
Hackernews is so strange. The post some weeks ago with the title "Show HN: Poli – An easy-to-use SQL reporting application built for SQL lovers" didn't get traction at all.
The main motivation behind the project is that I'd like to have an easy-to-use SQL to Dashboard web application that I can use to solve my own problem. I did try search and use existing BI tools first but found that they are either too complicated to setup/use or the license/fee is not friendly enough. I believe they are designed for more advanced user cases for a good reason and don't seem to suit my simpler needs. Thy's why I build Poli. Yes, I am the solo developer on this project.
Another BI tool worth checking out is one called A Reporting Tool(ART)[0]. ART has been around for well over 10 years. Not the classiest looking piece of software but it is packed with features BI people will appreciate. For starters it integrates with JasperReports. This means you can design reports for printing using Jasper designer. It integrates quite a few Java libraries allowing you to create reports using Excel and PowerPoint. LDAP integration is built in and it has a nifty scheduler allowing you to publish reports to FTP locations. It really is a nifty tool. Like I said it doesn't compete with the modern tools in terms of looks but it packs a whole lot of features. You configure your own JDBC driver and there is a JDBC driver for most databases and data stores.
BI = dashboards that are clicked through by consultants to manually generate reports that are read by management 5m every day while they take their morning shits
Wow, thanks! I have built many visualizations and dashboards using javascript and d3, and even just a couple of weeks ago was considering creating my own side-project to do just what this software does. I guess I'll be looking for a new project..
This looks fantastic! Since it runs as a self-hosted jar, is there any way to change the UI? Put it in a frame, style with CSS, call some JS for automation or report selection with parameters?
The UI is not configurable at this moment. You can embed the full screen view in an <iframe> and then adjust URL parameters to select which report to load.
I got it up in a few hours, and the included docker (compose) files are helpful, but it was a frustrating experience for a couple of reasons:
* There is some legal issue with the Apache foundation that’s preventing them publishing to PyPi (details about this were lacking).
* As a result, the provided dockerfile uses a very outdated version.
* Installing any missing dependencies means essentially building your own dockerfile anyways: in my case, it was the bane of my life Snowflake DB dependencies...
* Maybe it’s just me, but figuring out how to go from single-container ephemeral deployment to backend celery workers, external DB for persistence and a redos instance for caching (the recommended production setup) was frustrating to no end
* There are hosted versions you can use.
That said, we’re still going ahead with Superset, because it’s an improvement over the costly, ugly and over-opinionated alternative that is Tableau...
Thanks. The project is built mainly to solve my own problem that I often receive requests from the business side that they wanna access the data in the production system (We use different RDMS and Elasticsearch) so they can generate some simple charts in Excel and display to the customers. The request is not difficult but we just don't have a system for that. Since then, I have been trying different BI solutions like Power BI, Kibana and some other open source tools. They are either too complicated to setup/use or the license/fee is not friendly enough to me. That's why I build Poli. I want it to be more focusing on easy to use, having an open license and the developer can use SQL to build reports easily for the end users or embed the reports in their systems.
Hi dude,are you a hacker? Can you do me a favor to break into a illegal web in china(it's a web of bitcoin trade,but it's forbidden by Chinese government). It's a very simple job to a professional man. Contact me: xuechs@gmail.com. I wish your reply , and get money together.
I was a big fan of metabase (to the point I deployed it in 4 companies and rolled it out for many people to use in their daily workflow). All was nice.
Somewhere around 0.31 something changed in the internal dev/release flow. I get the feeling they have some kind of internal push to add unnecessary untested features which all look nice on paper, and work on a 5-row 5-column user tables. Until you actually use those features and all functionality fails miserably..
Had weird issues with it, which usually occurred after upgrades, on both small and bigger decently indexed DB's (pg and mysql), things like:
- had sets of reports which all worked fine until they hit a 1001 rows.. and suddenly the UI had a react race condition.
- X-Rays which silently fail and break the UI, while on the DB server you see the queries complete.
- Deployed new versions which would hammer databases by distincting every column individually every hour, instead of handling statistics a bit more intelligently. Disabled that ofcourse.
- Deployed versions in other countries, where the UI client-server latency caused the whole UI to break (probably the limits of setTimeout reached? :-)).
If you check the github issues, it's just ignored problems and they are focus on releasing new functionality instead of fixing the issues. Doesn't really motivate to report anymore problems.
They had one good thing: they would allow you to work in sql and write efficient queries, but clearly they decided it's time to remove the last good feature and now only want graphical query builders.
If you use metabase: deploy it on a replica such it doesn't whack your prod DB. And take backups before upgrading, because there is no revert.
I've spent enough time on Metabase problems, won't touch it anymore.
We've walked a fine line between fixing bugs, adding the features that our users have asked for and building out the BI interface we think the world should be using in 5 years.
We don't always get it right, and I'm sorry if we broke things for you on the performance side.
We will be spending a few of our development cycles after 0.33 to try to clear out our bug queue.
One specific factual point I'd like to reply to however - SQL isn't going anywhere. If anything we're making it easier to both write plain SQL, use SQL templates or use our graphical interface on top of SQL query results in our next release (preview at https://github.com/metabase/metabase/releases/tag/v0.33.0-pr...)
While I have you here... <nag> bump for the Athena driver. Also I can’t use Metabot without some privacy settings. Can’t anything be done? </nag>
From a review last year (so some of this may be outdated):
- Broader datasource support - 20 sources in Superset, vs 12 in Metabase
Superset supports:
- view creation by users ('create table as'), as well as materialization
- geo/GIS based visualizations
- day over day, week over week, etc. charting; moving averages, etc.
Superset is missing data catalog-like functions, which metabase has, though I didn't evaluate metabase's data catalog in depth. It also requires you to write SQL, where Metabase includes a query builder UI - though there was a rather strange difference in capabilities within Metabase between the SQL-based charting and the query builder UI.
I’ve taken a quick glance and looked at the code. It’s a Java/Spring Boot project which usually gets a lot of flak around here for “too much magic”.
This project is written in a very clean style and seems to use a minimum of Spring. Mainly rest controllers, configuration and and dependency injection. No hibernate/orm or AOP stuff.
This seems to be listed as a feature, which I find confusing. Not everything lives in SQL databases. Some things you extract for example from external APIs.
Is this basically "this is out of scope for the project", or it's a feature because we've got <alternative>?
This is even worse in 3d pie chart which doesn't even preserve proportions in areas/angles, so splitting in 4 parts, bottom/top will be larger than left/right.
EDIT: If you are showing who ate which parts of a pizza (to be pedantic) I'm sure a pie chart may be the best case solution. My favourite use of pie charts is to compare the harmonic series and the series 1/x^2, but then again this latter example is not really a traditional pie chart.
[0]http://art.sourceforge.net
I got it up in a few hours, and the included docker (compose) files are helpful, but it was a frustrating experience for a couple of reasons:
* There is some legal issue with the Apache foundation that’s preventing them publishing to PyPi (details about this were lacking).
* As a result, the provided dockerfile uses a very outdated version.
* Installing any missing dependencies means essentially building your own dockerfile anyways: in my case, it was the bane of my life Snowflake DB dependencies...
* Maybe it’s just me, but figuring out how to go from single-container ephemeral deployment to backend celery workers, external DB for persistence and a redos instance for caching (the recommended production setup) was frustrating to no end
* There are hosted versions you can use.
That said, we’re still going ahead with Superset, because it’s an improvement over the costly, ugly and over-opinionated alternative that is Tableau...
What is the story behind Poli?