Meteor 3.5 is out!. Meteor 3.5 is a broad release, and it… | by Meteor Software | Jul, 2026 | Meteor BlogSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Meteor Blog

The problem we kept running into<br>Limitation<br>The proof: real-world numbers<br>Change streams, getting statedTrade off

So, what else?DDP Session Resumption<br>DDP is now pluggable<br>Drop SockJS entirely<br>EJSON optimizations

The new accounts-express packageDDPRateLimiter

Node 24 and the invisible work<br>Where 3.5 fits in the Meteor 3 story<br>A note on how 3.5 got built<br>Upgrade, what is next, and thanks

Product releases, community news, and project updates about Meteor.js

Meteor 3.5 is out!

Meteor Software

12 min read·<br>23 hours ago

Listen

Share

Press enter or click to view image in full size

Meteor 3.5 is a broad release, and it earns the word. Its center of gravity is the reactive data layer, but the work reaches from the database driver out to your auth middleware and the Node runtime underneath. Here is the map, and everything below is covered in detail further down.<br>The headline is change streams by default : reactivity now works on managed and serverless MongoDB (Atlas Shared, Atlas Serverless) where the oplog was never available , so each instance does less work per subscription, your fleet gets smaller, and so does the bill. Around that sits the rest of the real-time modernization, with DDP session resumption that survives a dropped connection , a pluggable DDP transport with a uws option, a fully functional DISABLE_SOCKJS , and EJSON optimizations that trim allocations on the hot path. If you build APIs and auth, there is accounts-express for first-class authenticated routes, async DDPRateLimiter matchers, and client logins that are fully promise-based end to end . Underneath it all, the platform moves to Node.js 24 , with a handful of dependencies (MongoDB collation, OTPAuth for 2FA, http-proxy-3 ) quietly modernized so you don't have to think about them.<br>Change streams are where it starts.<br>The problem we kept running into<br>Meteor’s real-time updates rode on Mongo’s oplog: to know when data changed, every app server tailed the database’s replication log (a running record of every write to every collection) and filtered it, in your Node process, down to just the queries it cared about. It worked, but it carried two costs.<br>The first is that the oplog is the whole database’s write log, not just yours. Meteor tails all of it and throws away what it doesn’t need. The moment something outside Meteor wrote to the same database (a nightly ETL job, a data migration, a third-party service injecting records), every app server still had to read and discard all of that traffic . Your Meteor CPU bill went up because of writes your app never even made.<br>The second is that it tied you to self-managed Mongo. On managed and serverless tiers like Atlas Shared, the oplog is off-limits. So the moment you moved to the hosting most teams actually want, real-time broke, and your only fallback was polling: asking the database the same questions over and over, burning CPU and money to fake what should be instant.<br>Meteor 3.5 changes that. Change streams are now the default, real-time works on managed and serverless Mongo, and there’s no config to write.<br>And real apps are already reporting the difference, in public, with numbers.<br>Limitation<br>There is one requirement, and Meteor handles it for you: change streams need MongoDB 6+ running as a replica set or a sharded cluster. On older or standalone MongoDB, Meteor detects that it can’t use them and automatically falls back (to oplog, and then to polling). The same fallback covers cursors that use skip or limit and selectors change streams cannot serve. So the default is safe: you get the fast path where it works and a working path everywhere else, with no code changes and nothing to configure.<br>If you ever need the previous behavior, you can pin the pre-3.5 path for the whole app by setting packages.mongo.reactivity to ["oplog", "polling"] in settings.json (more on that, and the rest of the driver's tuning, below).<br>For the full picture, including how the observer driver selects and switches strategies, see the change streams observer driver docs. The feature landed in PR#13787.<br>The proof: real-world numbers<br>We could tell you change streams are faster. Instead, here is what the community measured. These are not vendor benchmarks run on hand-picked hardware to make a launch look good. They come from Meteor developers testing their own apps and load harnesses, and posting the results in public. Read them that way.<br>More connection capacity under load. In the official Meteor 3.5 announcement, forum member @italojs shared a load test comparing the two reactivity backends on the same app. Change streams sustained roughly 40% higher connection capacity than oplog. Under the same ramp, oplog hit out-of-memory crashes around 1,200 virtual users, while change streams stayed stable up to about...