5 ms·

I don't understand why you'd use SQLite for a deployment this heavy over PostgreSQL or MySQL. Yes, SQLite is fantastic, but why would you choose to do it this

I don't understand why you'd use SQLite for a deployment this heavy over PostgreSQL or MySQL. Yes, SQLite is fantastic, but why would you choose to do it this way?

emn13 8y ago
It's faster? Simpler? Conversely, why would you choose one of those alternatives? (I don't actually think there aren't any reasons to do so, mind you, but I can well imagine that if you really KISS, well - even at impressive sizes sqlite makes sense).
- vesak 8y ago
  SQLite's typing is rather weak, is it not? That might be a tad scary for someone used who relies on that part of PostgreSQL.
  - kjax 8y ago
    It sure is. After recently porting a large application from SQLite to Postgres, much of my time was spent casting types and ensuring code was updated to input the correct types into Postgres. All in all, the changes were for the better, as many bugs were discovered and resolved in the process.
- da_chicken 8y ago
  Well, the historic one is, "because you need multiple concurrent data writers." But, that's what this branch is supposed to be for. So now the reason is: "because you need multiple concurrent data writers from multiple processes." And it might also be "you need multiple concurrent data writers and care about your data enough to not risk loss in the event of a system crash or power failure" since it uses PRAGMA synchronous=OFF.
andrewguenther 8y ago
Because SQLite is often the right tool for the job, more so than Postgres and MySQL. It scales insanely well and requires minimal configuration and near zero administration. I try to use SQLite for as long as is feasible in my projects purely because it "just works". Don't let the "Lite" fool you. Depending on your needs, you can scale to 10s of thousand of users using just SQLite. Or not! It is all about knowing your system and properly evaluating your options. I choose to use SQLite because it often fits the use case of small to medium projects the best.
- deleted 8y ago
  [deleted]
- chubot 8y ago
  Honest question: where do Postgres and MySQL fall down for such deployments? What is the administration required? Backups? Users and permissions? Indices? FWIW I use sqlite for a personal wiki, i.e. a website with exactly one user :)
  - codefined 8y ago
    I think the idea is that if your service does more, it necessarily needs more work to maintain. From a simple point of view, there are just more moving parts to go wrong.
- deleted 8y ago
  [deleted]
- eismcc 8y ago
  The lite doesn’t refer to light, it refers to a “mineral”. https://changelog.com/podcast/201 https://changelog.com/podcast/201
  - oblio 8y ago
    I was confused by this, so I read the transcript. In case anyone else reads this, the name is supposed to be read as: SQL (S Q L or sequel, your call) - ite So it does sound like the name of a mineral: bauxite, boehmite, hematite, etc. Heck, kryptonite :D
  - TeMPOraL 8y ago
    > Jerod Santo: > Hm, like a mineral. Were you playing on the word "light", or were you just playing on mineral...? > Richard Hipp: > I was, I was. It's pronounced as a mineral. It's still a pun on "light". And an obvious one, given what SQLite is compared to other RDBMSes.
- api 8y ago
gcbw2 8y ago
I think it is a tradeoff. If you want more data resilience on disk, SQLite will require all sorts of hacks to (and more difficult, when) to dump to disk. On the other hand, if you need every ounce of performance and do not care so much about data resiliency on disk, then the other sql applications will be too much hassle to configure in a way you do not miss any of the many safeguards to save data they ship with by default, which will kill your performance when you least expect.

I don't understand why you'd use SQLite for a deployment this heavy over PostgreSQL or MySQL. Yes, SQLite is fantastic, but why would you choose to do it this way?

emn13 8y ago

It's faster? Simpler? Conversely, why would you choose one of those alternatives? (I don't actually think there aren't any reasons to do so, mind you, but I can well imagine that if you really KISS, well - even at impressive sizes sqlite makes sense).

vesak 8y ago
SQLite's typing is rather weak, is it not? That might be a tad scary for someone used who relies on that part of PostgreSQL.
- kjax 8y ago
  It sure is. After recently porting a large application from SQLite to Postgres, much of my time was spent casting types and ensuring code was updated to input the correct types into Postgres. All in all, the changes were for the better, as many bugs were discovered and resolved in the process.
da_chicken 8y ago
Well, the historic one is, "because you need multiple concurrent data writers." But, that's what this branch is supposed to be for. So now the reason is: "because you need multiple concurrent data writers from multiple processes." And it might also be "you need multiple concurrent data writers and care about your data enough to not risk loss in the event of a system crash or power failure" since it uses PRAGMA synchronous=OFF.

andrewguenther 8y ago

Because SQLite is often the right tool for the job, more so than Postgres and MySQL. It scales insanely well and requires minimal configuration and near zero administration. I try to use SQLite for as long as is feasible in my projects purely because it "just works". Don't let the "Lite" fool you. Depending on your needs, you can scale to 10s of thousand of users using just SQLite. Or not! It is all about knowing your system and properly evaluating your options. I choose to use SQLite because it often fits the use case of small to medium projects the best.

deleted 8y ago
[deleted]
chubot 8y ago
Honest question: where do Postgres and MySQL fall down for such deployments? What is the administration required? Backups? Users and permissions? Indices? FWIW I use sqlite for a personal wiki, i.e. a website with exactly one user :)
- codefined 8y ago
  I think the idea is that if your service does more, it necessarily needs more work to maintain. From a simple point of view, there are just more moving parts to go wrong.
deleted 8y ago
[deleted]
eismcc 8y ago
The lite doesn’t refer to light, it refers to a “mineral”. https://changelog.com/podcast/201 https://changelog.com/podcast/201
- oblio 8y ago
  I was confused by this, so I read the transcript. In case anyone else reads this, the name is supposed to be read as: SQL (S Q L or sequel, your call) - ite So it does sound like the name of a mineral: bauxite, boehmite, hematite, etc. Heck, kryptonite :D
- TeMPOraL 8y ago
  > Jerod Santo: > Hm, like a mineral. Were you playing on the word "light", or were you just playing on mineral...? > Richard Hipp: > I was, I was. It's pronounced as a mineral. It's still a pun on "light". And an obvious one, given what SQLite is compared to other RDBMSes.
api 8y ago

gcbw2 8y ago

I think it is a tradeoff. If you want more data resilience on disk, SQLite will require all sorts of hacks to (and more difficult, when) to dump to disk. On the other hand, if you need every ounce of performance and do not care so much about data resiliency on disk, then the other sql applications will be too much hassle to configure in a way you do not miss any of the many safeguards to save data they ship with by default, which will kill your performance when you least expect.