MongoDB takes a swing at PostgreSQL after claiming wins against rival NoSQL database vendor MongoDB says it is making significant gains against open source relational rival PostgreSQL in a claim that seems to fly in the face of recent research. Speaking as the company announced its second quarter results – which beat expectations with revenue up 13 percent to $478.1 million – CEO Dev Ittycheria …
I have been around considerably longer than that, but whereas my performance and reliability are perhaps not what they were, PostgreSQL seems to have been on a path of continuous improvement from a very solid base.
And its licensing is straightforward.
Agreed. And scalability and performance are largely a matter of database design. A poor design in any database just kills your performance.
It's surprising how few people know how to properly design a database model, even using something so simple as JPA.
This post has been deleted by its author
I'm really not sure Mongo is as popular as they think it is. Having used both MongoDB and relational database for years the problems of each system are many and varied.
For us it took ages to get user friendly results from Mongo due to the eventually-consistent nature of the default config but in return our production downtime was zero for several years whereas the relational database needed a proxy in front to handle updates without downtime and mistakes happened. But generally I feel that most data works well being saved in an atomic commit across tables.
I use MongoDB a lot, and it works really well for my use-case, but it is not for everyone.
I have lots of data (500m+ records) that I want to be able to read very quickly, and I don't care too much about write times. The way my data is organised gives me response times of around 10ms on FastAPI, but write times can be measured in hours or even days, because I'm basically pre-calculating every possible query and storing the results.
I really don't understand why (apart from peddling sales-wonk bollocks) anyone thinks there's a comparison to be made between NoSQL and relational dB platforms..? I'm not a dB expert, but even I can see that NoSQL is brilliant if you're Google or similar, and need to manage massive repositories of text - but I've always thought the noise made by NoSQL is out of proportion to number of real-world use-cases, compared to the relational databases which do the heavy lifting in most data-driven processes.
I have made a little framework, it is still a work in progress since covid. It use Postgres natively, but I have added little shims so it can be switched to use other DBs both relational and Mongo - because I wanted to gain a little experience with it. There is no benefit to this, the relational is simpler and better for most things. But if I was to need huge on a very available data storage layer that could be grown in situ without interruption, then Mongo might be it.
But then again, maybe not because scaled Atlas is quite costly.
"MongoDB was better for developer productivity"
I believe them. I've also championed introduction of MongoDB at a large financial group. It's good for what it does. I'm a little less convinced about the cost case for Atlas vs on-premises.
What I don't get is when we started caring about the developers. Even if it saves time for developers, what matters is the operations and the users. I'll happily take an extra 3 months development time for something I can just drop into production and forget about. Sharding Mongo on larger datasets can be a nightmare and it may as well be a different product in production than the one the Dev runs on their laptop/dev container, requiring different skills to manage so forget DevOps being the same guy.
Developer time is expensive and directly attributable to the project manager's budget, timeline and by inference bonus.
Operations time is a cost to be attributed to someone else and at a later time, i.e. not the PM's problem. It's also likely to be lumped into a big pot of looking after other systems, so the pain of one system gets hidden in among the noise. As such, it's fairly easy to see why developers may get the benefit.
There's also a trend over the last 10-20 years where it's cheaper to throw CPU, Memory and faster disk at a problem than it is to develop and code something which runs more efficiently. Why spend £200k on developer time to reduce CPU cycles by 25% when you can just double server capacity for £10k?
Like a typical dev this guy has no clue about the tech he's wielding but has clearly heard that doing "JSON documents", whatever those are, is hard or important or at least means something buzzwordy that makes people who control budgets nod along sagely as they pretend to understand.
Hint: its 40 years of life *is* postgres' selling point. Everything else it does it just gravy.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
