Not only is it a mongodb interface on postgresql, it's built by Microsoft, and has joined the Linux foundation? Color me surprised. Did they build this for fun or what?
pickle-wizard · 2026-06-29 15:50:36 UTC
Microsoft built this so they can have a MongoDB compatible database service for Azure.
A few years back MongoDB changed their license to AGPL to make it harder for companies to take their code and offer it as a service. They did this because it competes with the MongoDB Atlas service.
CodesInChaos · 2026-06-30 08:19:38 UTC
Mongo changed from AGPL, which is permissive enough to be usable by cloud providers, to SSPL which has even stronger copyleft making it unusable for cloud providers (and doesn't meet the OSI or FSF requirements).
pan69 · 2026-06-30 09:54:59 UTC
Not super familiar with Azure, but didn't they already have Cosmos DB? Or is that just MongoDB under the hood?
stackskipton · 2026-06-29 16:02:08 UTC
Beyond other reason listed in the comments, Microsoft is heavily invested in Postgres. They bought Postgres sharding company (https://www.citusdata.com) and apparently it sees a ton of use internally even for newer Greenfield projects. Also, if check recent commits to Postgres, you will find Microsoft employees all over commit history.
As I've commented several times before, MSSQL appears to be on life support. It makes them a ton of money and it's supported in same way AS/400 is supported. Sure, Microsoft will take your money but don't expect a lot in return.
schrodinger · 2026-06-29 18:15:47 UTC
As someone who spent over half a decade using MS SQL Server daily, I have to admit it's a very nice database, and better than Postgres for some use cases. This could be interesting!
Postgres made the foundational design decision that every update is an insert leaving behind a stale row that'll get cleaned up eventually with its MVCC model. It's great for non-blocking read-heavy workflows (presumably the most common), but it suffers for the inverse.
For example, I wrote a simple job queue in Postgres, which had a lot of contention over the oldest rows non-terminal rows. It had many runners trying to either mark a row as completed or claim a row by atomically marking it as started and returning the row's contents (using the "skip locked" functionality). This ran much faster using similar semantics on MS SQL Server or MySQL because they have in-place updates, not an append-only tuple log.
CodesInChaos · 2026-06-30 08:54:36 UTC
You might be interested in OrioleDB, which is an id-development storage engine for postgres that relies on in place updates combined with undo logs.
CodesInChaos · 2026-06-29 15:46:30 UTC
How does this related to other mongo on postgres projects? It looks like ferretdb was changed to build on documentdb and then abandoned?
marifjeren · 2026-06-29 15:48:18 UTC
Name it anything else for god's sake. DocumentDB is already what everybody calls Amazon DocumentDB
howToTestFE · 2026-06-29 15:56:15 UTC
+1 very confusing name for another mongodb compatible db.
cr125rider · 2026-06-29 16:20:07 UTC
But does this one support nice geospatial indexes? Ya know the one cool thing about mongo that AWS totally skipped
fabioyy · 2026-06-30 00:33:56 UTC
can't believe that is not intentional. fishy
schrodinger · 2026-06-29 17:56:11 UTC
Anyone notice how they linked to a "Hacker News Discussion" on their homepage? It's empty unfortunately, but hey, they tried!
Comments
A few years back MongoDB changed their license to AGPL to make it harder for companies to take their code and offer it as a service. They did this because it competes with the MongoDB Atlas service.
As I've commented several times before, MSSQL appears to be on life support. It makes them a ton of money and it's supported in same way AS/400 is supported. Sure, Microsoft will take your money but don't expect a lot in return.
Postgres made the foundational design decision that every update is an insert leaving behind a stale row that'll get cleaned up eventually with its MVCC model. It's great for non-blocking read-heavy workflows (presumably the most common), but it suffers for the inverse.
For example, I wrote a simple job queue in Postgres, which had a lot of contention over the oldest rows non-terminal rows. It had many runners trying to either mark a row as completed or claim a row by atomically marking it as started and returning the row's contents (using the "skip locked" functionality). This ran much faster using similar semantics on MS SQL Server or MySQL because they have in-place updates, not an append-only tuple log.
https://news.ycombinator.com/item?id=42807210