I love SQLite, but some arguments in the article seems contradicting each other.
1. Massive Max DB size vs It can't handle the traffic: If it can't handle the high throughput it doesn't matter how big it can get, because you never get there, you can't do 1 insert/sec and leverage 281 TB storage capability
2. It's just for small projects vs It can't handle the traffic: so it is for small projects, right? I know there are multitude of different types of applications, but when mentioned MySQL/PostgreSQL at the beginning of the article, I thought we would be talking about web/backend related applications.
SQLite has a different mental model, it wants to be simple and close to the code, hence you can't easily setup multi node replication
On the other hand, other databases want to manage your data in isolation, hence they're deployed on a separate machine and have out of box data replication/sharding mechanisms
My problem with SQLite is that I've been using it as a quick and dirty up-and-going weapon with easy backup solution, but even for small projects I find myself going multi-service or multi-node on accident. Really too easily.
I'm starting to think of using PSQL as my dirty up-and-going weapon.
I know we’re not supposed to whine about the medium but focus on the content. However, on Medium, the medium becomes the content because I can’t even read the damn thing without being accosted by some CTA popover. This is my quiet crusade against authoring on that platform.
Yup and authors are supposed to fit their content on a platform that never cared to equip them with tables, charts, or other forms of technical display. Even markdown on Github is way better for technical authoring.
I did, every time it pops up, I go "I guess we're not reading that then" and close the article. It's not like I _need_ to know about some guy's opinions on SQLite3, it's just entertainment. It is optional.
it is very very funny that Medium was initially a breathe of fresh air amongst the shitty, ad-ridden layouts of then-popular blogging sites, and has now deliberately made themselves unusable in turn.
I feel a bit bad if it's a human, but I can't even tell if this sort of vapid, uninteresting article was written by an LLM or just someone who is not good at writing and doesn't know much about the topic.
either way though, obviously humans should do whatever writing they but aggregators like HN should reject ones like this.
in which setup ? I don't think of a regular stack where you'd want a db stored as a file local to your api server. Can you store that sqlite file on a persistant ebs volume ?
1. Massive Max DB size vs It can't handle the traffic: If it can't handle the high throughput it doesn't matter how big it can get, because you never get there, you can't do 1 insert/sec and leverage 281 TB storage capability
2. It's just for small projects vs It can't handle the traffic: so it is for small projects, right? I know there are multitude of different types of applications, but when mentioned MySQL/PostgreSQL at the beginning of the article, I thought we would be talking about web/backend related applications.
SQLite has a different mental model, it wants to be simple and close to the code, hence you can't easily setup multi node replication
On the other hand, other databases want to manage your data in isolation, hence they're deployed on a separate machine and have out of box data replication/sharding mechanisms