Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

At a certain scale, you'll want replication or replication, which SQLite doesn't really do AFAIK. At a scale below that, you'll probably want to be able to have multiple web servers talking to one database server, which SQLite doesn't really do either. I also think SQLite's performance during heavy write workloads is worse than PostgreSQL's?

Basically, AFAIK, SQLite becomes problematic once you need more than one computer to handle requests.



Just to point out, there are now SQLite replication and various "distributed database" projects which seem to work fairly well.

They're probably not as battle tested as the PostgreSQL ones, but they are around, have users, and are actively developed.

The ones I remember off the top of my head:

* https://litestream.io

* https://github.com/rqlite/rqlite <-- more of a "distributed database using RAFT" type of thing

* https://github.com/canonical/dqlite


Yeah, there are SQLite forks or products built on SQLite which have these sorts of features, but SQLite doesn't. They remains reasons why someone may want to use another database (such as PostgreSQL, or an SQLite fork, or a database which uses SQLite as a storage engine) instead of SQLite.

Honestly though, if I need these sorts of distribution features, I would probably prefer the database to have them built in. I don't really see the point in using SQLite at that scale.


rqlite[1] creator here, happy to answer any questions.

[1] https://www.rqlite.io




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: