161–170 of 238 posts
Earlier quoted context omitted.
Sorry but MySQL was not really “better” than Postgres. I never understood back then why MySQL was the default choice for so many people.
Many claim that MySQL with default configs had various advantages over postgres with default config and that it had a far better replication story
I'm always cautious with a one-size-fits-all approach. If a team is working on a small project and SQLite works then great. You can use a SQLite database on something like a $4/month DigitalOcean droplet. Can't say the same for Postgres. > AI is a bubble Many say this but Generative AI and LLMs have gotten bunched up with everything else. There is a clear need for vectors and multimodal search. There is no core SQL s…
Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…
> This is exactly a great point. When data size goes to a billion rows, Postgres is tough. MongoDB just works without issue. Is it though ? Maybe 5-10 years ago it was.
Okay, I am very sorry that I got Rick Houlihan's name wrong. In my defense, I hadn't watched his talks _recently_ and we've all been Berenstain Bear'ed a few times. But also the comparison of DynamoDB/Cassandra to MongoDB comes directly from his talks. He currently works at MongoDB. I understand MongoDB has more of a flowery API with some more "powerful" operators. It is still a database where you store denormalized…
Earlier quoted context omitted.
Even without an ORM that supports both, as long as the DB layer is reasonably separated in your application it shouldn't be too much effort to switch. And if you've scaled to the point where it matters, you probably have the resources to do so.
>> as long as the DB layer is reasonably separated in your application I find this is easy in retrospect but tricky when you’re building a system. It’s all shades of grey when you’re building: Should I put my queue in my DB and just avoid the whole 2PC drama (saga is a more apt word but too much opportunity for confusion in this context). I probably should implement that check constraint or that trigger but should I…
It's only really easy if you push most of your constraints and triggers to the application. In practice, I've only ever switched databases with really simple CRUD stuff and have otherwise been able to predict that I'll eventually want Postgres/RabbitMQ/etc and build it in from the start.
I've found out key/value databases pushes for better architectural designs in enterprise environments. Especially in companies where different teams are responsible for a given business capability and it needs to scale above 1+ million users. Postgres flexibility enables for design that is hard to scale. Both in terms of maintainability and performance. Enforcing K/V as a default database in one of my previous compan…
As in: far enough that if you outscaled it, you'd be able to afford a team of excellent engineers to write an appropriate database system.
Almost all companies don't need the hyper scaling NoSQL databases supposedly promise. What they do often eventually realise is that they want the querying power and additional ACID guarantees of a typical relational database, so they end up developing a shitty relational database on top of a NoSQL database.
The "SQLite is just a file" thing is actually an advantage. The example of a website is actually a pretty poor one, since any website that needs to scale beyond a single box has many options. The two easiest ones are: - Mix static and dynamic content generation (and let's face it, most websites are mostly static from a server perspective) - Designate a writer node and use any of the multiple SQLite replication featur…
> if you use an ORM that supports both SQLite and Postgres you'll have the option to upgrade if your site brings in enough traffic I'll never understand this idea that Postgres and SQLite are somehow interchangeable when the time is right. My database and Postgres are _literally_ the core definition of everything that my application does. My app is written in Rust, but that doesn't matter because it's a _Postgres_ ap…
If by referential integrity you just mean FK constraints, you can turn that on in sqlite3.
I think SQLite is pretty good for a lot of use cases. An Axum/sqlite CRUD app should be able to handle at least few hundred requests per second on a medium powered box, which is good enough for a lot of things.
Postgres is really powerful but I don't think it's actually that common to structure your app around it's unique features.
> You can only have so much RAM. You can have a lot more than you'd think, but its still pretty limited compared to hard drives. Your data fits in ram[0]. [0]: https://yourdatafitsinram.net
eg on RDS, they'll give you instances with 1TB of RAM, eg a `db.r6idn.32xlarge`, at the nice price of $75/hr ($54k/mo). Not to mention that, in a microservices architecture, assuming you're not sharing a database, you might be multiplying that figure out a few times.
So just because it's possible for it to fit in RAM doesn't mean it's economical. RAM isn't exactly getting exponentially cheaper or more spacious anymore. The hope was flash memory would be the solution, but not sure how far that's getting these days.
Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…
Uh, 1 query per second is 60x60x60=216000... Soo, 1 million queries per hour equals 4-5 queries per second.
Soo, that's not even at toy project level. That's extremely low scale, like the smallest possible instance small.
A consumer laptop does 20+k queries/seconds on postgres, mysql etc. a raspberry pi usually still gets 1-3k read queries/s, depending on the used SD card (Or 432 million queries per second).
You're not instilling any kind of confidence quoting numbers like that
Almost all statements about MongoDB are wrong. > You know exactly what your app needs to do, up-front No one does. Mongodb still perfectly fits. > You know exactly what your access patterns will be, up-front This one also no one knows when they start. We successfully scaled MongoDB from a few users a day to millions of queries an hour. > You have a known need to scale to really large sizes of data This is exactly a g…
Personally, I've not seen any application that seriously needs a billion rows in a single table. (except at truly massive scale, but then you're not using Mongo)
The real solution is implementing archiving to a file store like S3 and/or ship it off to a data warehouse. You don't need billions of rows in a `record_history`/`user_audit` table going back 5 years in your production database. Nobody queries the data.