Hacker News Reader

Comment by kumarvvr | Hacker News Reader

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.

View on HN

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!

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.

> 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.

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.

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.

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.

> in almost all use cases

Including horizontal sharding and vertical replication out of the box?

It has both, but not out of the box.

More info?

What's vertical replication?

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

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.

> can comfortably be replaced by a single postgres primary

And lose all the data in a single failure?

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.

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.

I don't disagree at all with that statement although invetably what mongo does have out of the box definitely has its own quirks.

Getting operations right is tricky no matter what you're doing/using, and you always have to learn your backend's idiosyncracies no matter which one you choose.

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.

Reply on news.ycombinator.com