From the release notes of RC1:
• With the launch of new Metabase analytics, we’ll no longer write activity and view logs to Metabase Starter and Open Source; these logs will only be available on Metabase Pro and Enterprise.
Not happy. If you can't provide better functionality in the paid version to get people to upgrade, removing good functionality from the free version isn't the way to go.
Agree. Did anyone find the code that removes these views? We can probably make a fork with that piece re-enabled, right?
This is a critical piece to me since it enables me to understand which reports are viewed and which are not. I understand new UI features only being for pro users, but removing view logs seems extreme.
These activity logs are not a publicly facing feature or API we ever committed to maintaining.
They existed only to power paid features, and were being pre-populated on OSS + Starter instances purely to offer an "instant-on" trial experience of the paid features.
We have (and will continue) to add a lot of new features to the OSS version, and that's not going to change. However, we've had a set of paid features and will continue to iterate and refine those. I understand that some of the tables powering those features were useful in their own right but they were never announced as publicly facing OSS features.
TL;DR - the application database schema is not a public API that we are committing to maintain. It's an internal API that we can and will modify to best power our OSS and paid features.
That would be fine if Metabase had a suitable offering for the SME market.
5 users of Metabase Pro per month: $500
5 users of PowerBI per month: $50
5 users of QlikSense per month: $200
By the time Metabase Pro is comparable to PowerBI in price, PowerBI just moves users to their infrastructure pricing.
Both PowerBI and Qlik are for more powerful than Metabase and have better mindshare. Qlik are known for being expensive but have a superb product.
PowerBI's biggest disadvantage is the inability to send anything useful to people outside who don't have a licence. The difference in price more than makes up for that.
I'm also a Metabase open-source user who uses the activity and view logs table and will have my processes disrupted with this change .
What is the cost to Metabase to keep those tables in the open-source versions as well? The release notes mention that:
Those tables were never used in those editions of the product, and led to very large tables, which often increased the operational burden of self-hosted Metabase instances unnecessarily.
It seems that many open-source users are using it, so the first part is debatable. The second part of the sentence mentions that the tables become very large, which is a good point. However the next paragraph mentions:
Query execution, Audit, and View logs will be truncated for queries over two years old. You can configure this with the environment variable MB_AUDIT_MAX_RETENTION_DAYS.
What would be the downside of keeping those tables enabled on the open-source version, but with a lower retention period by default (like 2 weeks), and users could use the same environment variable to extend it if they want? That would remove the "becomes a very large table" problem.
Or actually, why not make those tables disabled by default, but create an environment variable so open-source users can enable them at their own risk, knowing that the schemas might change, that they have to develop their own dashboards, etc?
Seems a bit sad that when we set up Metabase Open Source, by default Metabase will gather usage events from us (and we can opt-out), but now we cannot even opt-in to have usage data ourselves on our installation.
I'm also a huge user of this tables that are really helping us to monitor internal traffic and Metabase adoption. I think that losing those data will really slow down the launch of Metabase for the companies on Open source and will make your product more difficult to implement.
I definitely agree that removing feature from open source version is not the fair way to develop business.
Please reconsider this move !
The env var MB_AUDIT_MAX_RETENTIONS_DAYS seems to be the solution. Unfortunately it isn't available on free plan.
Only available on Metabase Pro and Enterprise plans.
Sets the maximum number of days Metabase preserves rows for the following application database tables: query_execution [...]
If set to 0, Metabase will keep all rows.
Agree with everyone else on this issue. Please reconsider this move.
It's a red flag if Metabase team doesn't hear all these voices esp from older user (super helper).
I'm looking at another solution (as per writing this), if this really happening and we can't make Metabase team to reconsider it.
Thank you, @CZvacko! But I'm a bit confused now: based on Andrew's initial message, I had the impression that view_log would also cease to be active. Did the Metabase team decide to reverse this decision? (talking about Metabase Starter and Open Source here!)