3 ms·

> Lots of people saying that SQLite is super high quality I think the point most of those folks are making, is that SQLite is good enough where most developers

> Lots of people saying that SQLite is super high quality I think the point most of those folks are making, is that SQLite is good enough where most developers think "Psh, I will use [HEAVIER DB SYSTEM THAT SLOWS OVERALL DEVELOPMENT TIME]" even if it is a better long term solution. It's about bikeshedding, SQLite really is good enough for most projects and its a shame it still has such negative connotations.

maxbond 4y ago
For what it's worth I think it's largely overcome the reputation of being a "toy" database.
- robertlagrant 4y ago
  It never was a toy, so that's good.
  - maxbond 4y ago
    I'll plead guilty to having this impression until fairly recently, but it's an incredible database. While we were all not taking it seriously, SQLite was quietly getting better and better, year after year. You do that for a few decades and you've got an incredible piece of software.
eduction 4y ago
“Heavier” and “lightweight” are such abstract terms in software. If “heavier” just means more LoC — sure, there’s more complexity in more LoC but also more problems solved. There’s a reason people tend to use the latest Linux/macos/Windows as opposed to the very lightweight Apple II OS from 1978. Defaulting to, say, Postgres doesn’t seem so bad to me. It solves more problems than SQLite and “lightweight” is not really a concrete benefit for SQLite. It’s at least one level removed from speaking to a real problem.
- robertlagrant 4y ago
  It also causes problems. Now I have to worry about multiple processes instead of just one, and I need to upgrade it separately and test them both together.
  - deleted 4y ago
    [deleted]
- Quarrelsome 4y ago
  Lightweight means I don't need to install some shit on a server somewhere and hope that its reachable at the time I need to access it. If I'm a process running then I loaded from a disk somewhere which means I can in-process sqlite to write to that disk. Less stuff == less to go wrong == lightweight.
- throwawaymaths 4y ago
  I remember switching from postgres to MySQL and there was definitely a learning curve, so even without deployment costs (admittedly the same for mysql -- which were a real thing back then before RDS or Aurora or whatever hosted postgres)... It probably would have been better to use sqlite
- maxbond 4y ago
  I read them as "more/less complexity" not "more/less code". Postgres is heavier weight because it has more complexity; it has more features, it's networked, it has a more involved configuration process. They both have different advantages and can with in problem spaces the other can't. This is quite unlike the Apple II, which is outmoded and requires a dedicated hobbyist to get working. Postgres is an excellent default, but preferring lighter solutions does solve problems. It eliminates failure modes and cognitive load. As engineers we seek to eliminate the irrelevant to focus on the interesting. If you can use SQLite and avoid shipping a series of containers, and instead ship a single binary, you've eliminated things to think about. Neither of them is a silver bullet and you'll be a better engineer if you can do both.
  - 4y ago

maxbond 4y ago

For what it's worth I think it's largely overcome the reputation of being a "toy" database.

robertlagrant 4y ago
It never was a toy, so that's good.
- maxbond 4y ago
  I'll plead guilty to having this impression until fairly recently, but it's an incredible database. While we were all not taking it seriously, SQLite was quietly getting better and better, year after year. You do that for a few decades and you've got an incredible piece of software.

eduction 4y ago

“Heavier” and “lightweight” are such abstract terms in software. If “heavier” just means more LoC — sure, there’s more complexity in more LoC but also more problems solved. There’s a reason people tend to use the latest Linux/macos/Windows as opposed to the very lightweight Apple II OS from 1978. Defaulting to, say, Postgres doesn’t seem so bad to me. It solves more problems than SQLite and “lightweight” is not really a concrete benefit for SQLite. It’s at least one level removed from speaking to a real problem.

robertlagrant 4y ago
It also causes problems. Now I have to worry about multiple processes instead of just one, and I need to upgrade it separately and test them both together.
- deleted 4y ago
  [deleted]
Quarrelsome 4y ago
Lightweight means I don't need to install some shit on a server somewhere and hope that its reachable at the time I need to access it. If I'm a process running then I loaded from a disk somewhere which means I can in-process sqlite to write to that disk. Less stuff == less to go wrong == lightweight.
throwawaymaths 4y ago
I remember switching from postgres to MySQL and there was definitely a learning curve, so even without deployment costs (admittedly the same for mysql -- which were a real thing back then before RDS or Aurora or whatever hosted postgres)... It probably would have been better to use sqlite
maxbond 4y ago
I read them as "more/less complexity" not "more/less code". Postgres is heavier weight because it has more complexity; it has more features, it's networked, it has a more involved configuration process. They both have different advantages and can with in problem spaces the other can't. This is quite unlike the Apple II, which is outmoded and requires a dedicated hobbyist to get working. Postgres is an excellent default, but preferring lighter solutions does solve problems. It eliminates failure modes and cognitive load. As engineers we seek to eliminate the irrelevant to focus on the interesting. If you can use SQLite and avoid shipping a series of containers, and instead ship a single binary, you've eliminated things to think about. Neither of them is a silver bullet and you'll be a better engineer if you can do both.
- 4y ago