5 ms·

In "most cases"? I take it by most cases it means, non enterprise applications with no load and basic use-cases? I can't think of a single application for SQLit

In "most cases"? I take it by most cases it means, non enterprise applications with no load and basic use-cases? I can't think of a single application for SQLite at any company I've ever worked for, perhaps my first job for a small e-commerce company. Every database I work with has hundreds of GBs of data at the minimum and has to be highly available (i.e. tolerate any DB server dying with zero downtime) and in most cases, extremely low latency. I.e. respond to hundreds or usual thousands of requests per second with a response time ranging from 100ms to 1ms. Recently most of the databases I'm working with are responding to 10000+ requests per second at an average request time of less than 1ms. Sure, for embedded databases with not much data and a single user, use SQLite, but for actual serious applications it's a toy.

sdoering 6y ago
> but for actual serious applications it's a toy I tend to disagree. As do a lot of others [1]. [1]: https://www.sqlite.org/famous.html https://www.sqlite.org/famous.html
- saberience 6y ago
  Again, these are not distributed high throughput applications. This is a database as a bank-end for single user applications or otherwise small-scale usage.
  - mrweasel 6y ago
    There's a huge range between "a toy" and "high throughput applications", most of which are still serious business.
citrin_ru 6y ago
If you need HA then SQLite is out of the question, but query latency is usually lower than for MySQL/Postgres - with an embedded DB you are avoiding network latency. See also https://sqlite.org/np1queryprob.html https://sqlite.org/np1queryprob.html
- avinassh 6y ago
  what would be the tail latency when 1000s of requests waiting to write?
- saberience 6y ago
  How can you have an embedded database if you have tens or hundreds of application servers which all need to be able to access the same dataset?
  - citrin_ru 6y ago
    Of course it is not a good fit for SQLite. I was pointing out only that its latency is not bad (at least for for read mostly workload). There is common misconception that SQLite is OK only if the load is very low (<1rps), but in practice you can use SQLite for much higher load if you app stays within one host.

sdoering 6y ago

> but for actual serious applications it's a toy I tend to disagree. As do a lot of others [1]. [1]: https://www.sqlite.org/famous.html https://www.sqlite.org/famous.html

saberience 6y ago
Again, these are not distributed high throughput applications. This is a database as a bank-end for single user applications or otherwise small-scale usage.
- mrweasel 6y ago
  There's a huge range between "a toy" and "high throughput applications", most of which are still serious business.

citrin_ru 6y ago

If you need HA then SQLite is out of the question, but query latency is usually lower than for MySQL/Postgres - with an embedded DB you are avoiding network latency. See also https://sqlite.org/np1queryprob.html https://sqlite.org/np1queryprob.html

avinassh 6y ago
what would be the tail latency when 1000s of requests waiting to write?
saberience 6y ago
How can you have an embedded database if you have tens or hundreds of application servers which all need to be able to access the same dataset?
- citrin_ru 6y ago
  Of course it is not a good fit for SQLite. I was pointing out only that its latency is not bad (at least for for read mostly workload). There is common misconception that SQLite is OK only if the load is very low (<1rps), but in practice you can use SQLite for much higher load if you app stays within one host.