4 ms·

But why?(for a server) Postgres can run in a 256MB VPS(if one can find one these days) and has more features that you might need later. Installing is as easy

But why?(for a server) Postgres can run in a 256MB VPS(if one can find one these days) and has more features that you might need later. Installing is as easy as 'apt-get install postgresql', create user, create database, done.

xyzzy_plugh 7y ago
Furthermore, postgres has great replication, and a read-replica is trivial to set up. sqlite is amazing (for any embedded database, absolutely) but postgres can't be beat as a go to for server side.
- cyphar 7y ago
  To paraphrase the SQLite site: "SQLite isn't competing with [PostgreSQL]; it's competing with fopen(3)." The primary purpose is to replace custom (and fragile) single-file databases with something that is far more resilient and provides uniformity in implementation. The fact that it is a suprisingly good SQL database (to the point where folks are actively arguing that much more fully-fledged databases are better in some aspects) is incidental.
hardwaresofton 7y ago
SQLite is even easier to start with -- I'm not trying to say Postgres is not the right choice, but it is certainly a more complex choice. Postgres is a fantastic database, but most of the time getting started with and using SQLite will be easier. For example -- you'd never have to secure firewall rules to a SQLite instance. Bad defaults (unlikely but possible) or some bad post-install configuration and you've got an exposed server. I want to emphasize that my point about SQLite being viable for startups was with the assumption of a low-write high read workload -- most of the time queries won't even hit the DB but instead be served by some caching layer. It's also really easy to scale read only versions of your applications horizontally if all you've got to do is ship/swap out DB files (again at this point it might make more sense to look into a bigger DB and just scaling vertically).
throwaway_bad 7y ago
I have a small blog (using Ghost) that uses sqlite as the main database and it's incredibly easy to maintain. It's just a single file. For example if you want to back up, you just copy the file or add it to git. If you want to do a diff you just do sqldiff on two files. It is as easy as working with json or csv files, except with atomic writes and better querying. From their site: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html >SQLite does not compete with client/server databases. SQLite competes with fopen().
- majewsky 7y ago
  > For example if you want to back up, you just copy the file or add it to git. If you want to do a diff you just do sqldiff on two files. With Postgres, you run pg_dump on the database (which is a shell one-liner, only with slightly more arguments than cp) and that's even better for putting into git because it's a text file that git can diff natively and store efficiently with delta compression.
netol 7y ago
There is no real reason to use sqlite in web apps. Just use postgres and mysql, that's the the industry standard and you'll have less issues
- gunnihinn 7y ago
  Fewer.

xyzzy_plugh 7y ago

Furthermore, postgres has great replication, and a read-replica is trivial to set up. sqlite is amazing (for any embedded database, absolutely) but postgres can't be beat as a go to for server side.

cyphar 7y ago
To paraphrase the SQLite site: "SQLite isn't competing with [PostgreSQL]; it's competing with fopen(3)." The primary purpose is to replace custom (and fragile) single-file databases with something that is far more resilient and provides uniformity in implementation. The fact that it is a suprisingly good SQL database (to the point where folks are actively arguing that much more fully-fledged databases are better in some aspects) is incidental.

hardwaresofton 7y ago

SQLite is even easier to start with -- I'm not trying to say Postgres is not the right choice, but it is certainly a more complex choice. Postgres is a fantastic database, but most of the time getting started with and using SQLite will be easier. For example -- you'd never have to secure firewall rules to a SQLite instance. Bad defaults (unlikely but possible) or some bad post-install configuration and you've got an exposed server. I want to emphasize that my point about SQLite being viable for startups was with the assumption of a low-write high read workload -- most of the time queries won't even hit the DB but instead be served by some caching layer. It's also really easy to scale read only versions of your applications horizontally if all you've got to do is ship/swap out DB files (again at this point it might make more sense to look into a bigger DB and just scaling vertically).

throwaway_bad 7y ago

I have a small blog (using Ghost) that uses sqlite as the main database and it's incredibly easy to maintain. It's just a single file. For example if you want to back up, you just copy the file or add it to git. If you want to do a diff you just do sqldiff on two files. It is as easy as working with json or csv files, except with atomic writes and better querying. From their site: https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html >SQLite does not compete with client/server databases. SQLite competes with fopen().

majewsky 7y ago
> For example if you want to back up, you just copy the file or add it to git. If you want to do a diff you just do sqldiff on two files. With Postgres, you run pg_dump on the database (which is a shell one-liner, only with slightly more arguments than cp) and that's even better for putting into git because it's a text file that git can diff natively and store efficiently with delta compression.

netol 7y ago

There is no real reason to use sqlite in web apps. Just use postgres and mysql, that's the the industry standard and you'll have less issues

gunnihinn 7y ago
Fewer.