[throwaway20371]

"MangoDB is a proxy which uses PostgreSQL as a backend. The proxy translates MongoDB wire protocol commands into SQL queries, and use PostgreSQL as storage."

You don't have to support MongoDB, but you can support apps that were only written with Mongo as backend? That's awesome. I can't imagine it's production-ready yet but it's a great idea.

[kumarvvr]

I have seen multiple benchmarks that show PostgreSQL has better performance than Mongo in almost all use cases.

A simple wrapper in a language like Go or Rust is sufficient to surpass Mongo performance.

Personally, I have shifted database operations behind a GRPC service that uses Go language and PostgreSQL back-end. Allows me to customize the data store to suit the requirement.

PostgreSQL does not get enough love in this world.

[rustnote]

It's plenty loved, I'd say the most loved, but still a fair way behind Oracle in terms of popularity just because of legacy stuff. Damn legacy code, hecking JQuery was still the most used JS framework until just this year!

[kvdveer]

Oracle and popularity don't really go together. Oracle is really common, just like root-canal treatments. Wouldn't refer to either as popular, though.

[kumarvvr]

> but still a fair way behind Oracle in terms of popularity

I have a vague feeling that those who use Oracle are using it due to circumstance or corporate necessity.

[pydry]

One of the last straws for a job I had once was realizing that the oracle python client would convert money fields into float.

Oracle had its tentacles everywhere in that company. I think even they wanted to stop using it but it was just integrated to too much.

[strictfp]

Oracle is a hot mess but it also has some really powerful features, like table sharding , that actually works if you manage to set it up correctly.

[keyle]

To be clear, Oracle's popularity isn't popularity in the sense of popular folk love. Unless you mean popularity in the most rancid disgust available en masse.

[SergeAx]

> in almost all use cases

Including horizontal sharding and vertical replication out of the box?

[mst]

I've seen quite a few instances where a mongo deployment using both of those can comfortably be replaced by a single postgres primary (on about the same hardware as a single member of the mongo cluster) with a couple of read replicas and a connection balancer.

There are absolutely mongodb deployments out there that are at sufficient scale that they genuinely need those features in any storage backend, but I suspect the vast majority of them only need those features to work around mongo's mediocre straight line performance.

How close this comes to counting as "almost all" is of course highly arguable.

[SergeAx]

> can comfortably be replaced by a single postgres primary

And lose all the data in a single failure?

[mst]

I said a single -primary- and explicitly mentioned having replicas.

I'm very confused why you might think that could "lose all the data" from a single one of those nodes failing.

[SergeAx]

I was reading your reply too quick, sorry. Anyway, even failover replication in PG is not there out of the box and have it's quirks.

[kumarvvr]

It has both, but not out of the box.

[exelib]

More info?

[robertlagrant]

What's vertical replication?

[SergeAx]

Having several read-only replicas in every shard to distribute reading load.

[irq-1]

Off topic. What would you think of a 1 to 1 relation between gRPC functions and stored procedures? Keeping all the SQL together inside postgres is great for debugging and updates; you can see all dependencies. One to one would stop you from having to make a different API, and make the gateway a simple reusable service.

[inkyoto]

> You don't have to support MongoDB, but you can support apps that were only written with Mongo as backend? That's awesome. I can't imagine it's production-ready yet but it's a great idea.

You have just described AWS DocumentDB, which is a Mongo compatible frontend using Postgres as the backend (AWS coyly refer to it as Aurora, though); the wire protocol compatibility is at the version 4.0 level, with some extras thrown in. Change event streams also works like a charm. We have been using it for a couple of years and have found DocumentDB stable, performant with the AWS support being very good. Support for complex compound indices is still missing as well as support for complex query projections is somewhat missing, but we have decided to change ways of how we use use documents instead, so it has not become a major impediment for us.

The main disadvantage, though, is cost, especially for smaller datasets where spinning up a separate DocumentDB cluster quickly turns into a money wasting excercise. Although, for our primary use cases, DocumentDB is still more than 3x cheaper than a comparable Atlas MongoDB PaaS.

[julianlam]

Except DocDB is not a drop-in replacement despite what Amazon says.

People have tried and failed to get our software running on DocumentDB, whereas another developer got it running on CosmosDB with minimal changes upstream.

Not affiliated with MS in any way, just sharing what I've witnessed secondhand.

[inkyoto]

Amazon do not say that DocumentDB is a drop-in replacement, neither do I. Moreover, I have outlined specific incompatibilites between Mongo and DocumentDB we have encountered for our use cases; RBAC controlled document filtering is not available in DocumentDB, either. Therefore, it won't suit everybody.

However, for simple to medium complexity projects, especially for brand new ones, DocumentDB is a viable and a more affordable alternative to Atlas MongoDB with a decent level compatibility.

[taf2]

Didn't the stripe team do something like this 5 or 10 years ago? I seem to remember them having a translation layer or doing some sort of streaming conversion from mongodb to pg?

Ah yes - https://github.com/stripe-archive/mosql

6 years ago

[PeterZaitsev]

Does not look like the same thing - this looks like system to replicate from MongoDB rather than being able to talk to PostgreSQL as if it were MongoDB

[tyingq]

Yes, that seems correct

"MoSQL imports the contents of your MongoDB database cluster into a PostgreSQL instance, using an oplog tailer to keep the SQL mirror live up-to-date. This lets you run production services against a MongoDB database, and then run offline analytics or reporting using the full power of SQL."

[sitkack]

This also means you don't have to use PostgreSQL, you are using its wire protocol. So ideally, this could work with Cockroach, Yugabyte, Cloud Spanner, Crate DB, immudb and tens of others that I am missing.

[christkv]

There was another thing in that space aswell https://www.torodb.com

[michaelpb]

Yeah, I could imagine this being a useful step to migrate away from MongoDB. I suspect there are plenty of "resume-driven development" MongoDB installations out there that could use something like this.

[vosper]

> Yeah, I could imagine this being a useful step to migrate away from MongoDB.

What is the state of the art in this area? I did a little PoC of moving data from Mongo to a new schema in Postgres with Hexo and DBT. It worked nicely, but it was only a PoC.

[michaelpb]

Oh, I don't know about the state of the art, I was just speculating. I'd imagine this technique would only useful if you want to support a MongoDB app at the same time as building new features with Postgres, and then gradually phase out the MongoDB interface (e.g. gradually transitioning between a v1 prototype and a v2 rewrite)

If it's not much data (eg ~100k or something), and you don't need any sort of gradual transition, then I'd do something really KISS like dump into a CSV or something and then re-import with whatever the new database management system has for importing files

[threeseed]

MongoDB is a 12 year old database. And yet people are still using this disparaging argument that anyone that chooses it is doing so for their resume and not because it meets their needs in any way.

But by all means replace your production system with MangoDB which is unsupported, significantly slower, has no built-in HA/clustering and written in Go which is a GC language.

[dang]

Would you please not post in the flamewar style to HN? You have a long history of doing this, and I have the impression that it got better in the last few years (yay! thanks), but I also have the impression that you've been relapsing recently (boo, please don't). You can make your substantive points respectfully and without snark, and we'd be very grateful if you'd stick to that.

https://news.ycombinator.com/newsguidelines.html

[VWWHFSfQ]

It's crazy how this "flamewar" perspective has changed on HN about Mongo DB in the last 10 years. It used to be that any comment critical of MongoDB would get a warning. Now it's any comment supportive of it!

[dang]

> It used to be that any comment critical of MongoDB would get a warning

That can't possibly be true, or even close to true!

[michaelpb]

Hm, well, I never said that ANYONE who uses MongoDB is guilty of resume driven development. I specifically only indicated the ones that WERE chosen via resume driven development. Unless you were replying to the wrong comment?

[threeseed]

No I am replying to the right comment.

I think it's disparaging to use the term resume driven development as though there is a large class of developers who are actively trying to harm projects by selecting inappropriate technologies.

I've worked with thousands of developers over the last 20+ years and never seen anyone do this.

[michaelpb]

Huh, so if we are trotting out experience credentials, I have also worked with thousands of developers (I guess?) over the last ~20 years as well. My first programming language was Apple BASIC on an Apple II, and I haven't stopped learning since!

I think we use this term differently, perhaps? This term is not intended to be an attack, but rather just an acknowledgment of a common type of technical debt that results from people getting influenced by marketing teams and choosing tech based on how "trendy" it seems. Sometimes this might be done explicitly since they are intending to jump ship anyway... I've had conversations at the bar out of earshot of "the suits" where this exact topic was discussed! Most of the time it's not intentional or explicit, but just novice engineers directed by poor management to greenfield apps, and then falling for marketing claims and choosing based on how "trendy" the marketing claims it is vs real, observed needs. MongoDB is still getting taught at many bootcamps and coding curriculums as an "SQL, but better for beginners since you don't need that annoying schema thing!"

[matttb]

I've worked with tens of developers over 8 years and I've seen this many times.

I don't think they're 'actively trying to harm projects', but the person you're responding to never implied that in any way.

[michaelpb]

Yeah, I think the person we are replying to is taking this a lot more negatively than I intended. I always sort of thought it was kind of an "open secret" that this stuff went on, at least here in SV / Bay Area. Perhaps elsewhere, where engineers don't hop around jobs every year or two, this sounds more like an insult or accusation?

[marginalia_nu]

Allow me to doubt that you have deep insight into the motivations of thousands of people that have all selected MongoDB for their projects. This seems unlikely for several reasons, if nothing else because of Dunbar's number.

[threeseed]

I don’t need to have deep insights. Developers almost always have to justify why they pick certain technologies.

And given how old MongoDB is not sure how it benefits anyone’s resume.

[mapcars]

Since you haven't seen it means it doesn't happen? Sad that 20+ years didn't teach you basics of logic.

[ryanianian]

From the HN guidelines:

> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.

[PeterZaitsev]

Note MangoDB is a stateless proxy as such you can use it with any PostgreSQL setup. For example you should be able to use it with Amazon Aurora PostgreSQL as backend which has HA built in

[threeseed]

If you are using the cloud then you can just use DocumentDB.

[kdasme]

Which is the same proxy on top of PostgreSQL if I remember correctly. :) But MangoDB is cloud-agnostic. I imagine it has the same limitations as DocumentDB or more.

[kevinsundar]

But then you have to use DocumentDB.

[PeterZaitsev]

It depends. With MangoDB you can test on your laptop with PostgreSQL and deploy to Production to Aurora... or any other PostgreSQL compatible DBaaS.

[pulse7]

"and written in Go which is a GC language" => Would it be better for you if it would be "written in JavaScript which is a GC language"?

[zitterbewegung]

I agree either stay with mongodb or if you really want to migrate then just switch to Postgres by obviously exporting the data and putting it into Postgres

[jerrysievert]

I did something similar for fun 8-9 years ago as well: https://github.com/jerrysievert/mongolike

at the time it was much faster than native mongo.