But there’s a catch for people using transactions:
Batch Multi-Document Insert Operations
Starting in MongoDB 8.0, insert operations for multi-document transactions no longer produce individual oplog entries. Instead, multi-document inserts are batched as a single entry. The change stream insert event for each document has the same clusterTime.
This change increases performance of multi-document insert operations and eliminates possible replication lag caused by multiple oplog writes.
So both Meteor and oplogtoredis are affected (i.e., may no longer understand transactions; it’ll require an update in oplog handling if the format has changed (I guess it had to)) while changestream-to-redis is not (i.e., will work without changes).
Just a heads up to @storyteller now that the compatibility table explicitly excluded the current drivers as supporting mongodb 8 even if Atlas said otherwise
We will work on it in the next minor (3.1), which we should start sometime this week or next. I suspect our current driver version would break only some specific scenarios. In any case, v4.17 seems quite old to me and even surprising. Hopefully, there aren’t many accommodations we have to make in the core.
When I looked into this, the issue with v5 of the node driver is that callback have been removed. There is a transitional compatibility package, but that is a stop-gap measure.
We’re not using transactions at aleno, but I can confirm that Meteor 2.5.8 (I know, I know) with changestream-to-redis works just fine with MongoDB 8.0. We already updated our local and test environments (including E2E tests) with no issues whatsoever and plan to switch production soon.
EDIT: No, we’re not using any of the 8.0’s new features – we’re upgrading only for the performance improvements.
With all of the environments (including production) running on MongoDB 8.0 for some time now, I can confirm that the performance has improved a little for our workload:
Extremely heavy analytical aggregations are ~7% faster and use ~21% less CPU.
Average daily CPU usage is ~10% lower.
Average daily RAM usage is ~2% lower but significantly more stable.
Thanks for this info! Are these the impacts on your Mongo instance or the Meteor app? (If the latter, have you seen CPU/RAM usage improvements on the Mongo instance itself as well?)
I just received an email from Atlas that Mongo 6.0 is end-of-life (EOL) on July 31st, 2025 and that all clusters will force upgrade to Mongo 8.0. We hopefully will be upgraded to Meteor 3.x by then, but what happens if we’re still on Meteor 2.16?
As I wrote above, using older MongoDB driver is fine for most things, though the oplog format has changed. If you’re using changestream-to-redis, then you’re good to go. If not, I highly recommend testing it thoroughly, as it may just work for the most of applications. (One thing we know will not work are the multi-document transactions.)
Has anyone running 2.x and oplog tried to update? I’m wondering if it encouters the new format what the behaviour will be? I’m hoping it just throws an exception and continues ? We use some transactions but not really depending on the oplog results from them. I’m hoping the transactions themselves will still work ok.
For anyone still looking at this, I’ve found that they changed the description of the changelog and now it mentions
Batch Multi-Document Insert Operations
Starting in MongoDB 8.0, bulk insert operations outside of transactions may no longer produce individual oplog entries. Instead, MongoDB typically batches bulk inserts as a single entry. The change stream insert event for each document has the same clusterTime.
This change increases performance of multi-document insert operations and eliminates possible replication lag caused by multiple oplog writes.
So it seems like either they wrote it wrong, or people complained about this change and they went back to the previous way of working inside transactions.
In the same situation except Meteor 3 migration hasn’t even begun.
Has me a bit worried. I’m surprised more aren’t talking about this on here or that there aren’t any solutions! There has to be many in the same situation as this, no?
@Spyridon I know this is something to worry about, but from now on it will be increasingly important to migrate to Meteor 3, especially because soon we will no longer support Meteor 2 December 2025.
We just launched our 2.16 app on our staging and upgraded to Mongo 7 and so far haven’t seen any issues. We don’t perform transactions in our actual meteor code, only in our serverless code, but looks to handle it all well.
How’s everyones’ Meteor 3 migration going!? We just finished syntax. Now moving into Meteor and npm packages.
We’ve planned a re-work to basically either eliminate isomorphic code using collections or rewrite them so collection access is not needed. We hope by doing that to try keep our client side with minimal changes. Hoping to get stuck into it soon.
FYI, I just got a 30 day extension from Atlas support. Had to fiddle with them for three days in order to get it locked in. Just message them in the lower-right corner chat widget.
