Goodbye MongoDB
blog.stuartspence.ca
blog.stuartspence.ca
Sounds reasonable and not hype train driven
As opposed to?
You can use an SQL db engine as a kv-store, but you can probably make a more efficient kv-store if you do not have the SQL constraints.
(Oth SQL engines are pretty efficient for lots of use cases these days)
Another example where SQL may not be the right choice is time series or graph DBs.
Maybe I'm missing something, but wouldn't `db.coll.update_one(search_query, {"$inc": {"visit_count.api": 1}})` do the trick?
Overall, I've been very happy with MongoDB (and their Atlas serverless offering). I would still default to recommending Postgres "by default", but for those use cases where MongoDB makes sense, it shines.
I think that MQL is very difficult to write because of its verbosity—it simply requires so much text. Even as someone who regularly wrote and debugged MQL queries, it is just so verbose, but essentially is just an AST structure and doesn’t need that much verbosity. I created a library that attempts to solve that friction, but I have no idea if it’s still being maintained by MongoDB: https://github.com/mongodb-labs/pymongoagg
Seems like your library was last updated in April, though just basic maintenance. It looks pretty interesting! I might play around with it next weekend.
>versus the AWS shop where the Dynamo guy knew the innards of the database by chapter and verse)
Definitely has a big impact on it. The angle at which people approach these databases is completely different from my experience. MongoDB is advertised with words like "developer friendly" and "just works", so people tend to just start it up and not read too much into it.
On the other hand DynamoDB was described to us as "monkey's paw", "Carefully read before use", "know what you're doing". And so we combed through first all the pitfall blogs, then AWS documentation, and then carefully tried out all the features we wanted to use and tested the scenarios separately.
Also the SQL timestamp vs timestamptz thing is just silly and avoidable. I want to know who I complain to for that.
That's an issue with dynamo. Sure you can memorize the API, but you have no idea what is actually going on and aws support will NEVER tell you what is happening.
Postgres, Cassandra, etc are source available and yes I have multiple times looked at Cassandra code to figure out what it was doing.
Also, that's harder to do a proper Mongo implementation than to do a SQL implementation.
At a former workplace, when I stress tested the same API with different backend databases wired to it, Mongo was faster than Postgres. But we ended up using Postgres + Redis, because that combo was even faster than Mongo.
He has a smaller website and should be able to use mongo out of the box.
Complaining he didn't do indepth optimizations is ridiculous. He picked 2 database products and used out of the box configs.
Mongo should adjust their defaults if the defaults aren't using the product correctly
"I'm trying to stay humble. Mongo must be an incredibly big project with lots of nuance. I'm just a solo developer and absolutely not a database engineer. I've also never had the opportunity to work closely with a good database engineer. However I shouldn't be seeing improvements like this with default out of the box PostgreSQL compared to all the things I tried over the years to fix and tune Mongo."
But I would not assume that people in bigger companies are always experts in what they deal with either. It kinda matters how well something performs in non-ideal scenarios.
> How can we know he used Mongo properly or not?
You don't. I don't. This is just my story where I'm clearly not a junior but had a ton of problems with mongo.
>Choosing Mongo because you don't know SQL doesn't seem valid
Valid is such a strange word here. People choose technologies based on their current skills all the time. If you've never encountered that kind of decision before then you need more experience.
I always come back to Postgres.