Hacker News Reader

Comment by cpursley | Hacker News Reader

How is MongoDB still a thing when there's already several ways to handle json in Postgres including Microsofts new documentdb extension:

https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f...

What am I missing? Are Mongo users simply front end folks who didn't have time to learn basic SQL or back end architecture?

View on HN

I will copy and paste a comment I wrote here previously:

"MongoDB ships with horizontal sharding out-of-the-box, has idiomatic and well-maintained drivers for pretty much every language you could want (no C library re-use), is reasonably vendor-neutral and can be run locally, and the data modeling it encourages is both preferential for some people as well as pushes users to avoid patterns that don't scale very well with other models. Whether these things are important to you is a different question, but there is a lot to like that alternatives may not have answers for. If you currently or plan on spending > 10K per month on your database, I think MongoDB is one of the strongest choices out there."

I have also run Postgres at very large scale. Postgres' JSONB has some serious performance drawbacks that don't matter if you don't plan on spending a lot of money to run your database, but MongoDB does solve those problems. This new documentdb extension from Microsoft may solve some of the pain, but this is some very rough code if you browse around, and Postgres extensions are quite painful to use over the long term.

The reality is that it is not possible to run vanilla Postgres at scale. It's possible to fix its issues with third party solutions or cobbling together your own setup, but it takes a lot of effort and knowledge to ensure you've done things correctly. It's true that many people never reach that scale, but if you do, you're willing to spend a lot of money on something that works well.

> MongoDB ships with horizontal sharding out-of-the-box

Maybe it's better than it was, but my experience with Mongodb a decade ago is that that horizontal sharding didn't work very well. We constantly ran into data corruption and performance issues with rebalancing the shards. So much so that we had a company party to celebrate moving off of Mongodb.

> my experience with Mongodb a decade ago

So before the Apple Watch was released.

Why is this relevant today ? Technology changes very quickly.

And Apple Watch still sucks as an actual watch vs a Casio.

MongoDB is not the same as Postgres and jsonb.

also, I'd challenge your thinking - ultimately the goal is to solve problems. you don't necessarily need SQL, or relations for that matter. that being said, naively modeling your stuff in mongodb (or other things like dynamodb) will cause you severe pain...

what's also true, which people forget, is naively modeling your stuff with a relational database will also cause you pain. as they sometimes say, normalize until it hurts, and then denormalize to scale and make it work

the amount of places I've seen that skip the second part and have extremely normalized databases makes me cringe. it's like people think joins are free...

Then your implementation can be as simple as CREATE TABLE documents (content JSONB);. But I suspect a PK and some metadata columns like timestamps will come in handy.

sigh - mongoDB is not the same as creating a table with jsonb. for one, you don't have to deal with handling connections. that being said, postgres is great, but it's not the same.

Postgres has ways to simplify connection management, if that is a blocker for you (pooling, pgbouncer, postgrest, etc)

I have seen a few rather large, production mongodb deployments. I don't understand how so many people chose it as their basis of their applications. There are a not-negligible amount of mongodb deployments I have seen that basically treat mongodb as a memory dump, where they then scan from some key and hope for the best. I have never seen a mongodb solution where I thought that it was better than if they just chose any sql server.

SQL or rather just some schema based database has a ton of advantages. Besides speed, there is a huge benefit for developers to be able to look at a schema and see how the relationships in the data work. Mongodb usually involves looking at a de facto schema, but with fewer guarantees on types relations or existence, then trawling code for how its used.

If you're scared of SQL/have a massive operations team to throw infrastructure problems over the fence then that would be a positive to push all complexity into the application code as you aren't the one paying that cost.

We use their atlas offering. It’s a bit pricey but we are very happy with it. It’s got a bunch of stuff integrated - vectors, json (obviously), search and charting along with excellent support for drivers and very nice out of the box monitoring.

Now I could possible spend a bunch of time and do the same thing with open source dbs - but why? I have a small team and stuff to deliver. Atlas allows me to do it fast.

There’s a ton of hosted Postgres providers that do all of that and more and are just as simple to use. Neon.tech is really easy to set up and if you need more of a baas (firebase alternative), Supabase. Plus, no vendor lock in. I’ve moved vendors several times, most recently AWS RDS to Neon and it was nearly seamless. Was originally on Heroku Postgres going way back. Try getting off Atlas…

Ha - easier said than done in an enterprise, especially when nothing is wrong. Maybe the $$, but at some point the effort involved with supply chain and reengineering dwarfs any “technical” benefit.

This is why startups like to get into a single supply chain contract with an enterprise - it’s extremely hard to get it setup, but once done very easy to reuse the template.

Similar here, there are gotchas though. Some versions ago they've changed their query optimization engine - some of our "slow aggregations" become "unresponsive aggregations" because suboptimal indexes were suddenly used. We had to use hints to force proper indexing. Their columnar db offering is quite bad - I'd say if there's need for analytical functionality, its better to go with a different db. Oplog changes format - and although its expected, it still hurts me every now and then when I need to check something. Similarly at some point they've changed how nested arrays are updated in changestream, which has broken our auditing (its not recommended to use changestream for auditing, we still did ;) ). We've started using NVM instances for some of our more heavily used clusters. Well it turned out recovery of an NVM cluster is much much slower than a standard cluster. But all in all I really like mongodb, if there are no relations - its a good choice. Its also good for prototyping.

It's simply not that widespread of knowledge. Modern Postgres users would never suggest Mongo, but a generation of engineers was taught that Mongo is the NoSQL solution, even though it's essentially legacy tech.

I just ran into a greenfield project where the dev reached for Mongo, and didn't have a good technical reason for it beyond "I'm handing documents". Probably wasn't aware of alternatives. FWIW Postgres would've been a great fit for it, they were modeling research publications.

If you can learn Mongo you can learn SQL and 'back end architecture' let's be honest the basics are hardly difficult no matter what tool you're using.

Just because Postgres is good doesn't mean other things can't also be good (and better for some use cases).

Enterprise sales

Mongo is Firestore for entrprise

Yes

Reply on news.ycombinator.com