Great and shows how meteor can be extended. Just wondering about your opinion about using Postgres in parallel without removing mongodb/minimongo(using it only for Accounts) ā¦is it an overheadā¦or does it complicate things or does it cause other issues.
Thanks
It would be great to see PostGres-based accounts become an officially-supported Meteor option!
Hello @satya,
I congratulate you on your successful use of PostgreSQL with Meteor. Although I donāt use PostgreSQL myself, I have much respect for it and take an interest in projects that combine it with Meteor.
I am the defacto maintainer of the Meteor MySQL integration (vlasky:mysql). Instead of using the Mongo oplog, the Meteor MySQL integration implements reactive queries and publications using the MySQL binary log as the event source, in a manner compatible with Mongo on the client side.
I strongly disagree with parts of your article disparaging the use of reactive publications and subscriptions in Meteor. I have quoted them at the end.
As I write this post, customers across Australia are tracking their food and alcohol deliveries in real-time using Meteor webapps developed by my businesses that leverage reactive MySQL publications to update maps and tables with order status updates as well exchanging instant messages between drivers and dispatchers.
We have found using publications to be more efficient and performant than having the client needlessly poll the server. They greatly reduce latency and the amount of data sent over the wire.
So why are some people having difficulty scaling Meteor apps that use publications?
1. Meteorās reactive Mongo driver is missing a critical throttling feature - a minimum interval between successive query result set fetches.
Publications are most often used to update a UI component on the client side. If a collection is receiving many updates per second, it is pointless and wasteful to push data to the client for each one.
Instead, what if you could specify a minimum interval of say 1 second between updates? This would greatly reduce bandwidth use as well as CPU/IO overhead on the client and server.
This key performance-enabling feature has long been present in the Meteor MySQL integration and I have urged for it to be implemented in Meteorās Mongo driver and also in redis-oplog.
2. Out of the box, Meteorās server-side merge box stores a copy of the collection data for each user who subscribes to the publication.
As long as your server has enough RAM and your Node.js process is configured to use it by passing the --max-old-space-size argument on the node command line, you should not get into trouble.
Development efforts are already underway to provide finer control over the behaviour of the mergebox that I expect to alleviate this problem for good.
PR#11368 - Support for publication strategies in livedata server
PR#11151 - Initial support for publication strategies in livedata server
This is a technology that was very cool when Meteor launched, and it has its uses. But itās also the main bottleneck for Meteorās performance. It adds load to the server, and to the database. And honestly, real-time can be solved in many ways these days.
As a rule of thumb: donāt use Meteorās publications, they will always cause you headaches. Simply use websockets (or Meteorās DDP) to inform the client of changes, and then have the client fetch data by API.
Donāt use Meteorās publications, itās useless by default due to performance implications and will always cause you headaches.
In other words, Meteor must stay tightly coupled to Mongo, because of its real-time publications offering. But that technology is quite useless by default due to its performance implications, and therefor should not be used.
@satya, the first part of your article, describing the benefits of Meteor, could be also be published independently. It would be a great resource for those looking for the latest info.
Also, have you considered possibly doing a pull request containing your PostGres-based accounts as an optional account system for Meteor? That way the community could take a look at it and vet it for potential official inclusion. Just a thought!
First thanks and great to get your input/feedback!
These 2 were serious issues with Publications that we ourselves ran into multiple times, so we decided never to use Publications again. At a certain point in time servers will run to 100% CPU or 100% memory.
But, perhaps the issue is fixed - although git still reports it
Iām curious, if youāre not interested in the Mongo integration and reactive data layer, which parts of Meteor do you like?
But this isnāt publications per se, right? Itās just a benefit of using websockets. In fact if your client doesnāt support websockets you are needlessly polling the server.
My understanding of the OPās criticism is that itās not of the āpush changes over the wireā model, but the way that Mongo detects those changes and pushes them to the right clients (oplog tailing, mergebox) which makes them inefficient and hard to scale.
The answer is in my article 
We are comparing the performance impact of polling for updates by performing periodic Meteor method calls with the performance impact of sending updates using Meteor publications/subscriptions.
Both operate over WebSockets unless you are in running an an environment where WebSockets are unavailable and long polling mode is then used as a fallback.
The first advantage with publications is that the server can send to the client at any time of its choosing, ensuring minimal latency, set by the reactivity response time. In contrast, when performing periodic Meteor method calls, the latency is determined by the polling period plus the method completion time.
The second advantage with publications is that they avoid all that recurring Meteor method-related data going over the wire and the server-side CPU/IO load required to service the method call - an unavoidable consequence of polling.
The disadvantages with publications are the need for the server-side code to consume RAM for the merge box and the overhead of following the MongoDB oplog or MySQL binlog. I have already discussed the remedies for these two issues.
Oh my apologies, itās literally in a list of bullet points. 
Hi @satya
Iāve recently been concerned about the MongoDB license, and wondered if Meteor.js is still the right solution for my new projects because of the very limiting SSPL license, which makes hosters very scarce ā¦
Are you still using your accounts implementation with Meteor after these years? Is it running well?
I also like that thereās a MySQL implementation, but my reason to consider other DBs is not that I love SQL, itās just the license of MongoDB is concerning, and that of MySQL isnāt much better, as far as I know. Thatās why Postgres is interesting.
Anyway, would love to hear peopleās experience with using Postgres or another truly open source DB with Meteor in a production setting!
Try FerretDB 2.0 with PostgreSQL. I will also try when I have some time.
No, from my perspective Meteor has become irrelevant technology. All good things come to an end 
This sounds and looks amazing! Thanks a lot for sharing this.
Do you have this running for a production app? Howās the performance? Any compatibility issues?
I will definitely try this out myself also.
Thatās a pretty extreme statement - which isnāt a problem in my book, but it makes me very curious why you think Meteor has become an irrelevant technology; and what are you using now as an alternative to get an MVP up fast?
Do you have this running for a production app? Howās the performance? Any compatibility issues?
Not yet, because I need install newest version and test.
No, from my perspective Meteor has become irrelevant technology.
Hehe, according to someone at Internet, everything is already dead.
Even when Meteor is using newest Node.js, and there are many large production apps running Meteor 3, like RocketChat.
I would also like to know, what you currently use instead. I like to try new stuff.
Arlight, I tried out FerretDB 2.2 (latest) locally (with a Meteor repo without much functionality, but more than a fresh installation).
Itās very easy to get started locally with Docker: GitHub - FerretDB/FerretDB: A truly Open Source MongoDB alternative
I instantly got Deadlock errors caused by the accounts-password package trying to create sparse indexes, which are not supported yet in FerretDB.
However, I was able to create a shim/patch for the functions that create indexes and published that as package here: The trusted source for JavaScript packages, Meteor.js resources and tools | Atmosphere
(follow the instructions in the README; especially, add the package before the accounts packages in .meteor/packages).
Will keep testing out FerretDB. Would be great to see other test it out as well.
Hi Satya would be interesting to learn more about why you think this technology is irrelevant. I think you are partially right, and the parts you might be right about might have been irrelevant for many for a very long time.
I havenāt used Publications for at least 8 years. I adopted React from its first releases and found Redux to work best with what I need to do.
I donāt use Cordova or Meteor Desktop, and I am pretty fine with React Native or PWA (being a React dev. anyway).
Now my AI tools are pretty fine with understanding my Meteor specifics, and it helps me a lot.
I started a couple of DB-less websites in React to have them hosted with Netlify, and I found myself doing them in Meteor too :)) ā¦ because it is fun and joy.
If I could get CDN cached dynamic components, I would be the happiest developer (in my house).
I also need to get into passing Methods (DB queries) through Redis, I found the solution, and I just need to allocate some time for wiring things right. This is similar to redis-oplog but for methods.
I recently tried NextJS (again). I just canāt stand the fetching syntax and concept and I hate the way images are being imported and some other parts that had to be made a NextJS React component. I am also not a big supporter of SSR because I consider that the cost of tech should be shared between the provider and consumer - Iāll give you some JS ā¦ you HTML it yourself. Of course this works ok up to a certain bundle size but works better for apps with recurrent visits such as SaaS or social networks etc. SSR is great for the first visit but I couldnāt find another use for it in what I do. I host my own Prerender so I will only pay $5 a month to have all the buggers out there crawl my pages.
Iām correcting my own statement of earlier: the deadlocks were not caused by FerretDB not supporting sparse indexes. FerretDB 2.2 does support sparse & unique indexesāgreat! The deadlocks were causes by the accounts-base and accounts-password packages concurrently creating such indexes, which is handled well by MongoDB, but not well by FerretDB/Postgres. I updated my package to fix only what is essential to avoid this error, by simply making createIndexAsync sequential (using a promoise chain).