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.
Hey @AndrewMBaines and @sicarul -
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.
-Sameer
While i understand what you are stating, the fact is that when the new Metabase version comes out, we’ll have a difficult choice, we’ll either:
All of these are bad scenarios, i urge your team to reconsider this.
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.
@AndrewMBaines it seems the flag that enables these logs is located here:
Further irony is that my 'Metabase Metadata' post is the 2nd most viewed post in the FAQs! Frequently recommended by the Metabase employees on here. 
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.
Hi there,
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 !
Thanks
Losing Metabase metadata is a nonsense.
I had dashboard based on metabase.query_execution to monitor adoption, processes respect, broken questions, abnormal use and more.
This regression is unacceptable and calls into question Metabase on my next projects.
I understand that you enhanced your paid version by adding more features but removing from the open version is a bit cripy.
We use this table to check if queries are slow, or how much are we using Bigquery, so we can check very heavy queries and so on...
Do you know any way so we can check who/how much/when inside BQ?
Hi, I hope this move gets reconsidered.
We use telemetry data to monitor Metabase adoption within the company.
Without this feature, we are blind.
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 to0, 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.
Who are you calling 'old'? 
Hi everyone ! Anybody knows if these tables were actually removed in v0.48 ?
If you mean the activity + audit_log tables, they are not removed, but no new data appears in there. Only the view_log remains active.
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!)
That's true, I mention that in my reply. Even in Open Source, new data appears there.
Seems like they have finally pulled the trigger. What a shame. Is anyone aware of a fork?