Hacker News new | ask | show | jobs
by tuyguntn 536 days ago
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

1 comments

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.