3 ms·

Not in its current state - it becomes entirely unsuitable as soon as you need to have multiple instances (be it for scalability or availability). Sqlite is inh

by 3np 6y ago

Not in its current state - it becomes entirely unsuitable as soon as you need to have multiple instances (be it for scalability or availability). Sqlite is inherently single instance. What really makes this an issue is that it doesn't work safely/reliably on distributed filesystems like GlusterFS and Ceph. See here for example of a project that needs to be forked in order to not have data corruption on remote filesystems (it depends on the WAL mode AIUI): https://github.com/Sonarr/Sonarr/issues/1886 https://github.com/Sonarr/Sonarr/issues/1886 I really do hope that this will be addressed in a future version of Sqlite, which would at least allow running it on redundant network-attached storage. But even if it is, you will still have issues once you want to scale horizontally for performance. If you're building strictly in-house proprietary software, none of this really matters as you have full control. But if it's either FLOSS or otherwise to be operated by anyone else than the developer and their internal organization, SQLite is not suitable. I die inside a bit every time I am expected to take responsibility for a software built on Sqlite.

gwd 6y ago
From TFA: The only time you need to consider a client-server setup is: - Where you have multiple physical machines accessing the same database server over a network. In this setup you have a shared database between multiple clients. - If your machine is extremely write busy, like accepting thousand upon thousands of simultaneous write requests every second, then you also need a client-server setup because a client-server database is specifically build to handle that. - If you're working with very big datasets, like in the terabytes size. A client-server approach is better suited for large datasets because the database will split files up into smaller files whereas SQLite only works with a single file. I have run SQLite as a web application database with thousands concurrent writes every second, coming from different HTTP requests, without any delays or issues. This is because even on a very busy site, the hardware is extremely fast and fully capable of handling that. The claim is that most of the time you don't actually need multiple instances.
- 3np 6y ago
  Not covered: Single application server with network-attached highly available storage

by 3np 6y ago

gwd 6y ago

From TFA: The only time you need to consider a client-server setup is: - Where you have multiple physical machines accessing the same database server over a network. In this setup you have a shared database between multiple clients. - If your machine is extremely write busy, like accepting thousand upon thousands of simultaneous write requests every second, then you also need a client-server setup because a client-server database is specifically build to handle that. - If you're working with very big datasets, like in the terabytes size. A client-server approach is better suited for large datasets because the database will split files up into smaller files whereas SQLite only works with a single file. I have run SQLite as a web application database with thousands concurrent writes every second, coming from different HTTP requests, without any delays or issues. This is because even on a very busy site, the hardware is extremely fast and fully capable of handling that. The claim is that most of the time you don't actually need multiple instances.

3np 6y ago
Not covered: Single application server with network-attached highly available storage