3 ms·

“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 pro

“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.
- eduction 4y ago
  This is an enlightening answer. Part of my issue with “lightweight” is that is is vague. I see it used all the time. In this case, if people mean “way less configuration than Postgres,” and “does not need its own service and process(es) to manage,” that makes total sense. And it also gives a hint as to the tradeoffs.
  - maxbond 4y ago
    This made me smile, thanks for keeping an open mind, stranger.
gjulianm 4y ago
Not really. Heavier and lightweight usually refer to the amount of features and requirements of a piece of software. In that regard, it's easier to see which of PostgreSQL and SQLite is lighter. PostgreSQL requires a separate process running with its own config, plus the library to communicate with it, plus all the things Postgres does... On the other hand, SQLite is just a library that reads files in a certain format. > It solves more problems than SQLite and “lightweight” is not really a concrete benefit for SQLite. But it is a concrete benefit. Sometimes you'll have restricted environments because either by power or by permissions, you can't install Postgres or any other database server (e.g., mobile phones or embedded software). Or sometimes you just don't want the user to configure their postgres instance and your software for just a few tables (e.g., system utilities/small services that just need a simple database).
freeopinion 4y ago
Here's one concept of heavy vs light: I have often wished I could just email a small Pg db to a colleague. In the same way I can just attach a single file to an email and transmit an entire SQLite DB. I'm not dissing Pg. I really love Pg and I understand that it's built the way it is for good reasons. But it sure would be awesome to pg_dump and have a single tar that could be "run" with a single pg command without worrying about which version is required, what configuration is required, etc. When that convenience is the most important requirement, SQLite wins. But that is hardly ever the biggest consideration in which RDBMS I choose.
- KronisLV 4y ago
  > Here's one concept of heavy vs light: I have often wished I could just email a small Pg db to a colleague. In the same way I can just attach a single file to an email and transmit an entire SQLite DB. The closest to this I've gotten is being able to run MySQL/MariaDB/PostgreSQL/other solutions in containers locally and sending archived data directories, with which they can be launched anywhere else locally, or on server. I actually had a blog post about how that looks on my servers for other applications: https://blog.kronis.dev/articles/how-i-migrate-apps-between-servers-in-2021 https://blog.kronis.dev/articles/how-i-migrate-apps-between-... For PostgreSQL, it could look like: 1. run PostgreSQL in a container, e.g. https://hub.docker.com/_/postgres , use a bind mount for the data directory, /var/lib/postgresql/data 2. once you want to share, use tar/something else to archive the local bind mount directory 3. send the archive and the command to run the container through e-mail or whatever else you prefer And on the receiving end: 1. receive the run command and attachment 2. unarchive the data directory into a folder 3. run the container with the provided command It's not perfect, but it's one of the more portable methods I've found (though there are file system issues between Linux and Windows sometimes, like when running PHP apps).
acuozzo 4y ago
It's SQLite… like a mineral/rock. Graphite, Titanite, Erythrite. Not "SQ Lite".

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.

eduction 4y ago
This is an enlightening answer. Part of my issue with “lightweight” is that is is vague. I see it used all the time. In this case, if people mean “way less configuration than Postgres,” and “does not need its own service and process(es) to manage,” that makes total sense. And it also gives a hint as to the tradeoffs.
- maxbond 4y ago
  This made me smile, thanks for keeping an open mind, stranger.

gjulianm 4y ago

Not really. Heavier and lightweight usually refer to the amount of features and requirements of a piece of software. In that regard, it's easier to see which of PostgreSQL and SQLite is lighter. PostgreSQL requires a separate process running with its own config, plus the library to communicate with it, plus all the things Postgres does... On the other hand, SQLite is just a library that reads files in a certain format. > It solves more problems than SQLite and “lightweight” is not really a concrete benefit for SQLite. But it is a concrete benefit. Sometimes you'll have restricted environments because either by power or by permissions, you can't install Postgres or any other database server (e.g., mobile phones or embedded software). Or sometimes you just don't want the user to configure their postgres instance and your software for just a few tables (e.g., system utilities/small services that just need a simple database).

freeopinion 4y ago

Here's one concept of heavy vs light: I have often wished I could just email a small Pg db to a colleague. In the same way I can just attach a single file to an email and transmit an entire SQLite DB. I'm not dissing Pg. I really love Pg and I understand that it's built the way it is for good reasons. But it sure would be awesome to pg_dump and have a single tar that could be "run" with a single pg command without worrying about which version is required, what configuration is required, etc. When that convenience is the most important requirement, SQLite wins. But that is hardly ever the biggest consideration in which RDBMS I choose.

KronisLV 4y ago
> Here's one concept of heavy vs light: I have often wished I could just email a small Pg db to a colleague. In the same way I can just attach a single file to an email and transmit an entire SQLite DB. The closest to this I've gotten is being able to run MySQL/MariaDB/PostgreSQL/other solutions in containers locally and sending archived data directories, with which they can be launched anywhere else locally, or on server. I actually had a blog post about how that looks on my servers for other applications: https://blog.kronis.dev/articles/how-i-migrate-apps-between-servers-in-2021 https://blog.kronis.dev/articles/how-i-migrate-apps-between-... For PostgreSQL, it could look like: 1. run PostgreSQL in a container, e.g. https://hub.docker.com/_/postgres , use a bind mount for the data directory, /var/lib/postgresql/data 2. once you want to share, use tar/something else to archive the local bind mount directory 3. send the archive and the command to run the container through e-mail or whatever else you prefer And on the receiving end: 1. receive the run command and attachment 2. unarchive the data directory into a folder 3. run the container with the provided command It's not perfect, but it's one of the more portable methods I've found (though there are file system issues between Linux and Windows sometimes, like when running PHP apps).

acuozzo 4y ago

It's SQLite… like a mineral/rock. Graphite, Titanite, Erythrite. Not "SQ Lite".