3 ms·

Can you give a specific example of what you are missing when using SQLite?

endisneigh 3y ago
Multi writer, access through the internet without 3rd party software, etc.
mort96 3y ago
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.
- justinclift 3y ago
  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://litestream.io * https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite <-- more of a "distributed database using RAFT" type of thing * https://github.com/canonical/dqlite https://github.com/canonical/dqlite
  - otoolep 3y ago
    rqlite[1] creator here, happy to answer any questions. [1] https://www.rqlite.io https://www.rqlite.io
  - mort96 3y ago
    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.
lisasays 3y ago
Here's a good place to start: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html https://www.sqlite.org/quirks.html https://www.sqlite.org/quirks.html Full-scale RDBMSs, especially Postgres, have lots of goodies that either SQLlite doesn't have (or which it does have, but which aren't so richly featured). Once you've gotten hooked on a few of these, the distinction will feel a lot more clear. Meanwhile the tipping points in favor of SQLite seem to be embedded systems, and its whole "service-less" architecture and plain ease of use. Which is why it still gets lots of love, for those contexts.
Avamander 3y ago
Performance, especially after a while and certain size.

Multi writer, access through the internet without 3rd party software, etc.

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.

justinclift 3y ago
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://litestream.io * https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite <-- more of a "distributed database using RAFT" type of thing * https://github.com/canonical/dqlite https://github.com/canonical/dqlite
- otoolep 3y ago
  rqlite[1] creator here, happy to answer any questions. [1] https://www.rqlite.io https://www.rqlite.io
- mort96 3y ago
  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.

lisasays 3y ago

Here's a good place to start: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html https://www.sqlite.org/quirks.html https://www.sqlite.org/quirks.html Full-scale RDBMSs, especially Postgres, have lots of goodies that either SQLlite doesn't have (or which it does have, but which aren't so richly featured). Once you've gotten hooked on a few of these, the distinction will feel a lot more clear. Meanwhile the tipping points in favor of SQLite seem to be embedded systems, and its whole "service-less" architecture and plain ease of use. Which is why it still gets lots of love, for those contexts.

Avamander 3y ago

Performance, especially after a while and certain size.