3 ms·

The only real difference between SQLite and something like Postgres or MySQL is that Postgres and MySQL bundle a networking layer on top of their embedded DB en

The only real difference between SQLite and something like Postgres or MySQL is that Postgres and MySQL bundle a networking layer on top of their embedded DB engines. If you are worried about high availability, chances are you too are building a networking layer on top of a database, so what do you need two networking layers for?

pjmlp 4y ago
And stored procedured, debugging, JIT compilation, extension in multiple languages, ....
beoberha 4y ago
Do people build their own networking layers above SQLite (besides for fun)? If you’re doing that, then you need to build some kind of replication story. At that point it makes sense to just use PG or MySQL
- randomdata 4y ago
  Unquestionably. Web apps and the like which are little more than networking frontends to a database are probably the most common type of software written these days.
  - beoberha 4y ago
    Ah, we’re talking about different things. I took “network layer” to mean something like the ability to connect directly to the database over the network, not through some shim application.
    - randomdata 4y ago
      Meaning something like rqlite[1]? The age of fat desktop clients all connecting back to the central SQL server is long behind us, so yeah there is probably little reason beyond fun for something like that these days, but where there is fun! [1] https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite
- password4321 4y ago
  Ha! PostgreSQL still needs some kind of replication story! ;) (PS. Mostly just pointing out that replication is still a bit awkward.)
Aperocky 4y ago
I broadly agree, however running a cache/networking layer is difficult, and is handled well by other open sourced implementations. If someone already wrote that networking layer, why would I want to do it again? And run into all of the bugs that they already discovered and solved?
- randomdata 4y ago
  Agreed, although we are having this discussion now exactly because those same problems are starting to get solved for SQLite in an open and polished way, so it is no longer a case of needing that second networking layer to integrate with such solutions.
ngrilly 4y ago
Most apps nowadays are HTTP APIs on top of a database, which means we have one networking layer – the HTTP API – on top of another networking layer – the database protocol. The idea behind using SQLite is to just skip the latter, which is simplifying the stack significantly and reducing the database latency, which is making things like 1+n not a problem anymore. With a tool like LiteFS, it is now possible to get replication done by a sidecar process: https://fly.io/docs/litefs/ https://fly.io/docs/litefs/
snovv_crash 4y ago
It's because people are using super slow languages which incur lots of overhead in running the queries and formatting the results into human readable form. As such they need many more machines to run these webapp machines than they do to run the database itself.

pjmlp 4y ago

And stored procedured, debugging, JIT compilation, extension in multiple languages, ....

beoberha 4y ago

Do people build their own networking layers above SQLite (besides for fun)? If you’re doing that, then you need to build some kind of replication story. At that point it makes sense to just use PG or MySQL

randomdata 4y ago
Unquestionably. Web apps and the like which are little more than networking frontends to a database are probably the most common type of software written these days.
- beoberha 4y ago
  Ah, we’re talking about different things. I took “network layer” to mean something like the ability to connect directly to the database over the network, not through some shim application.
  - randomdata 4y ago
    Meaning something like rqlite[1]? The age of fat desktop clients all connecting back to the central SQL server is long behind us, so yeah there is probably little reason beyond fun for something like that these days, but where there is fun! [1] https://github.com/rqlite/rqlite https://github.com/rqlite/rqlite
password4321 4y ago
Ha! PostgreSQL still needs some kind of replication story! ;) (PS. Mostly just pointing out that replication is still a bit awkward.)

Aperocky 4y ago

I broadly agree, however running a cache/networking layer is difficult, and is handled well by other open sourced implementations. If someone already wrote that networking layer, why would I want to do it again? And run into all of the bugs that they already discovered and solved?

randomdata 4y ago
Agreed, although we are having this discussion now exactly because those same problems are starting to get solved for SQLite in an open and polished way, so it is no longer a case of needing that second networking layer to integrate with such solutions.

ngrilly 4y ago

Most apps nowadays are HTTP APIs on top of a database, which means we have one networking layer – the HTTP API – on top of another networking layer – the database protocol. The idea behind using SQLite is to just skip the latter, which is simplifying the stack significantly and reducing the database latency, which is making things like 1+n not a problem anymore. With a tool like LiteFS, it is now possible to get replication done by a sidecar process: https://fly.io/docs/litefs/ https://fly.io/docs/litefs/

snovv_crash 4y ago

It's because people are using super slow languages which incur lots of overhead in running the queries and formatting the results into human readable form. As such they need many more machines to run these webapp machines than they do to run the database itself.