In deinem eigenen Text steht völlig korrekt, wann SQLite passt: ‚read-heavy but not write-heavy‘ und wenn man kein ‚multiversion concurrency‘ (MVCC) braucht. Während das auf die in deinem Zitat genannten ‚web applications‘ aus deiner Webdesign-Bubble wunderbar zutrifft, ist ein zentraler Reverse-Proxy mit aktivem Access- und Tunnel-Logging unter Last eben kein Sinatra-Web-Cache, sondern massiv write-heavy. Genau wegen des Single-Writer-Locks von SQLite bietet Pangolin nativen Postgres-Support inklusive ausgelagerter postgres_logs-DB und Read-Replicas an.(Mal ganz abgesehen davon, dass ein Benchmark, in dem Redis angeblich nur 250 rpm bei 150 ms schafft, ohnehin unfreiwillig komisch ist). Wer natürlich nur in den Dimensionen einzelner Webseiten denkt, für den bleibt eine lokale Datei selbstverständlich der Gipfel der Enterprise-Infrastruktur.
Mein ich ernst und nein, Blödsinn (rhetorisch) wie Shopify gehört nicht zu den Use Cases.
We created a Sinatra (ruby) solution which caches production data using SQLite, and then compared it to a similar solution using Redis, using siege to stress the two systems and then compared the numbers:
Throughput (rpm) Response time (ms) SQLite 1800 6 Redis 250 150 SQLite is best suited for production use in applications that:
- Desire fast and simple setup
- Require high reliability in a small package
- Have, and want to retain, a small footprint
- Are read-heavy but not write-heavy
- Don’t need multiple user accounts or features like multiversion concurrency snapshots
These criteria describe a significant percentage of web applications, internal tools, and even customer-facing products. But teams often dismiss SQLite because it doesn’t match their mental model of what a “serious” database looks like.
.