> <i>A spokesperson at MongoDB said: "The rise of MongoDB imitators proves our document model is the industry standard. But bolting an API onto a relational database isn't innovation – it's just kicking the complexity can down the road. These 'modern alternatives' come with a built-in sequel: the inevitable second migration when performance, scale, and flexibility hit a wall."</i><p>I think the reason that a there are so many MongoDB wire compatible projects (like this postgres extension from microsoft, and ferretdb) is because people have systems that have MongoDB clients built into their storage layers but don't want to be running on MongoDB anymore, exactly <i>because</i> "performance, scale, and flexibility hit a wall".<p>If you can change the storage engine, but keep the wire protocol, it makes migrating off Mongo an awful lot cheaper.
I've said it as a joke many times that PostgreSQL can be a better NoSQL database than many actual NoSQL databases just by creating a (text, JSONB) table.<p>You can do actual searches inside the JSON, index the table with JSONB contents etc. Things that became available in MongoDB very very late.
The word is it's a serious effort on the part of Microsoft. It's missing a MongoDB wire protocol which they plan to opensource as well. In the meantime it's possible to use FerretDB for that.<p>I think the biggest use case is big data and dev platform that need application compatibility and wrapping Atlas is less attractive for some reason.
I really don't see the point of this compared to Postgres' native JSON support.<p>And with things like this in the source <a href="https://github.com/microsoft/documentdb/blob/a0c44348fb473daf75b8950d0118201c0b3e6d19/pg_documentdb_core/src/planner/selectivity.c#L24">https://github.com/microsoft/documentdb/blob/a0c44348fb473da...</a><p>I'd definitely stay away from it.
I was hoping this was an implementation of the schemaless indexing [1], which is the foundation for Azure DocumentDB.<p>That design allows arbitrary nested JSON data to be indexed using inverted indexes on top a variation of B-trees called Bw-trees, and seems like a nice way of indexing data automatically in a way that preserves the ability to do both exact and range matching on arbitrarily nested values.<p>[1] <a href="https://www.vldb.org/pvldb/vol8/p1668-shukla.pdf" rel="nofollow">https://www.vldb.org/pvldb/vol8/p1668-shukla.pdf</a>
I wish PostgreSQL would support better syntax for JSON updates. You can use `->>` to navigate the JSON fields, but there's nothing similar for updates. You have to use clumsy functions or tricks with `||` and string casting.
My biggest gripe with MongoDB is the memory requirements, which did not become immediately obvious to me when I was first using it. If you index a field, Mongo will shove every record from that field into memory, which can add up very quickly, and can catch you off-guard if you're not accounting for it. It is otherwise a fantastic database that I find myself being highly productive with. I just don't always have unlimited memory to waste, so I opt for more memory friendly SQL databases.
This looks promising. I am using MongoDB in my application because the data is document oriented. I did take a brief look at using JSONB in Postgres, but I found it a lot harder to work with.<p>I would prefer to use Postgres as my database, so this is worth investigating. Taking a brief look at the github page, it looks like it will be easy to swap it out in my code. So I think I know what I'll be spending my next sprint on.
Microsoft silently hates NoSql document data storage.<p>The complexity of maintaining a relational database is at the core of their proprietary business model.<p>For operational systems, documents are just better in every way.<p>Leave the rdbms for analytics and reporting.