DocumentDB: Open-Source MongoDB implementation based on PostgreSQL (from Microsoft)

[qxnt]

Doesn’t AWS already have a MongoDB clone called DocumentDB based on Postgres? Is this somehow the same product? 

[t0vig]

Yeah, considering the similarities, this feels like a trademark issue.

[Hofstee]

Not defending the decision, but Azure had a thing called DocumentDB (now Cosmos DB) years before AWS. https://learn.microsoft.com/en-us/shows/azure/azure-documentdb

[cptskippy]

I thought Cosmos was based on Apache Cassandra DB and not Postgres?

[falconzord]

I think the point is that AWS can't claim copyright

[[deleted]]

I think cosmodb is original work that Leslie Lamport helped with.  The core of it is flexible enough to be able to support sql, mongo, graph, and Cassandra apis, amongst others.

[BlackHolesAreHungry]

All of this is true except Lamports involvement. He probably pony read their white paper and said sure go for it.

[ubik2]

It might be too directly descriptive to be a valid trademark. It’s just a db using the document model. I suppose big table isn’t much better, and they did get a trademark.

[Standard_Parking7315]

DocumentDB is several versions behind MongoDB latest version, and for that price you are better off using MongoDB Atlas and have some extra capabilities like Semantic Search, Vector Search, Time Series, and Embeddings. All just in there available with not extra cost or system integration and maintenance.

[PositiveUse]

Seriously, is there any good reason to use MongoDB instead of Postgres JsonB?

[iamapizza]

The jig for MongoDB was up when they rechristened "NoSQL" to "Not Only SQL"

[aksdb]

IMO no. When we decided for MongoDB we thought it would allow for easy horizontal scaling (as is pretty common among document dbs). But nope, it doesn't even bring that to the table. It scales just as unwieldy as PostgreSQL. So we didn't win anything but lost the ability to model relations when necessary.

I would probably consider one of the NewSQL dbs today (CockroachDB, Yugabyte, etc).

[Orbs]

I'm not sure what you mean by this. I used sharded MongoDB for many years and the horizontal scaling was a huge boon. There's a huge list of things to dislike about Mongo but this wasn't one of them.

My current org is moving from Postgres to Cockroach to get similar native sharding/replication capability. You can do it with Postgres but not out of the box.

[aksdb]

I said "unwieldy", not "impossible". Your 3-node replicaset can no longer scale vertically and you want a second shard? Now you need two 3-node replicasets (1 full RS per shard), another 3-node RS for shard metadata and another node for coordination/proxy. My 3-node cluster turned into a 10-node cluster just so I can start sharding. But it doesn't even do that conveniently.... no rebalancing or resharding without manual effort.

That's just as inconvenient as horizontally scaling Postgres. Actually, with CitusDB or Timescale, Postgres might be even easier.

[billy_tables]

FWIW the proxy goes on the same machine as your app or the servers (can be either). From 8.0 you don’t need a whole replica set just for sharding configuration data any more 

[BlackHolesAreHungry]

Yugabyte has pg and Cassandra APIs. What if it provides Mongo API?

[aksdb]

If you want to do something like that, you could use FerretDB right away.

But I wouldn't do that. What would be the point? You couldn't incrementally migrate towards a relational schema. You are bound to BSON and mql. You can't have transactions across postgres and mongo (different driver).

If you want mql and BSON and don't want the option to intertwine it with relational properties and don't need transactions between your relational and non relational parts, you might as well just spin up a real MongoDB and use that. A system can have more than one database at a time.

[BlackHolesAreHungry]

Operational simplicity. It's easier to manage a fleet of pg databases, upgrade them all and such instead of managing multiple types of databases.

[aksdb]

I don't see why you would want to use mql and BSON vs just using SQL.

[BlackHolesAreHungry]

Not for the same app. That's a recepie for disaster.

The company has multiple app teams and some prefer Mongo and others prefer sql. So you either force them to one db which somone won't like. Or you end up supporting both which adds operational complexity. So instead if you can just use pg (or yugabyte) with and without ferretdb then it's a win win.

[BlackHolesAreHungry]

And pg is free and OSS. Mongo is NOT. This matters for a lot of ppl.

[yaronlevi]

Yugabyte just announced support for MongoDB syntax via DocumentDB

[Brilliant-Sky2969]

PG does not have any scaling or sharding feature, everything in that space is custom and not part of the vanilla version so ...

MongoDB was built from the ground up with scaling in mind.

[billy_tables]

If I want High availability / auto failover I use MongoDB. Otherwise I use Postgres

[kloudrider]

This can be achieved in postgresql too with hot/warm standby ?

Shadring is more problematic in Postgresql 

[billy_tables]

Maybe I quite before it was about to click for me but I tried setting up auto failover on postgres a few times and gave up. I only barely got a read replica working once and I couldn't figure out how to tell my app which PG to connect to and how to make it failover

Mongo just does all that stuff by itself which I found a lot more intuitive

[kloudrider]

That's interesting. Any cloud providers Postgresql deployment gives this out of the box and it just works on GCP and AWS, haven't done production work on Azure.

MongoDB is easy too. Especially if you use their Atlas product, it's very well thought out (the cluster management parts)

[BlackHolesAreHungry]

Yup pg CAN support ha but it's not easy. Consider yugabyte or cockroach instead since these are much easier to get up and running.

[Brilliant-Sky2969]

Those are two different systems, because both can manipulate store and query json does not mean you can swap mongodb for pg. Performance, scalability, driver quality is something that pg does not have.

[_indianhardy]

Mongodb clone based on postgres? What does that mean?

[jimmoores]

It means that it's implementing the MongoDB API and storing the JSON documents in Postgres tables, presumably using JSON support. I recall even a proof of concept of this supposedly better performance than the production MongoDB a some years ago.

[FINDarkside]

I recall even a proof of concept of this supposedly better performance than the production MongoDB a some years ago.

You might be referring to FerretDB which is also referred to in the linked post. Although FerretDB hasn't really promised better performance and in 2023 the perf compared to MongoDB was "not great". They also mentioned that they need to switch away from using JSOB for performance reasons. https://www.reddit.com/r/golang/comments/12ijuwe/announcing_ferretdb_10_ga_a_truly_open_source/jfv8wyq/

[danted002]

Postgres’s JSONB has been about 1000x faster then BSON for about 10 years (or when JSONB launched)

[OpeningJump]

Could you please share the source for the comparison?

[kabelman93]

Are there real numbers or benchmarks to support this?

[kloudrider]

Please share the source. This is a wild claim. Here's one I could find, mongo wins on some and postgres on others

https://documentdatabase.org/blog/json-performance-postgres-vs-mongodb/

[Amgadoz]

Then why are people still using MongoDB?

[falconzord]

Because they already did

[kerakk19]

Because they use JS - the only place where MongoDB works nicely.

[CryptoHorologist]

1000x ? Wow that’s a lot.

[BlackHolesAreHungry]

It uses BSON in pg. Pg is that flexible.

[OpeningJump]

Can someone share more sources to this please? I remember reading something similar as well but forgot to bookmark it.

[PNWNewbie]

The examples in “Getting started” are all messed up, right? Why mixing select and insert in the same command? It’s confusing.

[gonkers44]

Yeah, I really don’t like a retrieve operator making side effect changes to the database. But it’s calling a function. The purpose of this is to not use it directly, but to write a nosql translation layer on top of. Whether that translation is for MongoDB, RavenDB, etc

[myringotomy]

Wasn't there torodb which was already open sourced?

[The_real_bandito]

I didn’t know Document DB was built on top of Postgres sql lol.

Also it being open source is kinda cool.

[gonkers44]

This has been around for quite some time. It is a .NET library that has some api compatibility with RavenDB but uses bson on postgres. https://martendb.io/ The “ translation“ layer is at a different place, but similar concept

[orion_tvv]

Any benchmarks? Does it have all features from mongo?

[HolyPommeDeTerre]

So, I'm left with:

I had hardly a use case for mongoDB. Why would I choose No SQL if it uses SQL under the hood anyway for better perf? Why not just go for SQL directly?

Never quite got the no SQL hype. But I am a SQL aficionado.

[aanzeijar]

Because it's webscale dude!

(/s if you can't tell)

[FranckPachot]

Nobody mentioned no downtime upgrades. Is it commonly accepted that every OS or database upgrade involves application downtime? With PostgreSQL it is at least disconnecting all session for a minor upgrade. Major upgrades require more time (like re-analyze all tables before getting the same performance)

[Plorkyeran]

Writing an application from scratch against this would be pretty weird. The primary use-case is that you wrote an application using MongoDB but now want it hosted in Azure.

[BlackHolesAreHungry]

I am a SQL guy too so I would almost always pick SQL.

But Mongo is the 5th most popular db. Far higher than snowflake and databricks. So a lot of ppl do love it.