Databases Compared
SQLite: The Most-Deployed Database Most Admins Ignore
SQLite is the embedded database in every browser, phone, and aircraft panel on earth, and the doctrine that it is a toy is the most reliable sign someone has not audited its limits. Serverless, file-based, transactional, and absurdly stable across versions: it belongs in a surprising share of small-system work, and the discipline around files and locking is the only honest learning curve.
Key points
- Serverless is a feature, not an absence: a library call away, no daemons, no network socket, no configuration; for single-process analytics plus small apps, deployment surface approaches zero.
- Concurrency is the constraint that limits it: WAL mode adds concurrent readers with one writer; N-Threads-of-writers across several independent processes is a design smell immediately: the database file is not intended for multi-hosting.
- Storage honesty: the file IS the database, which makes backups simple (live copies via .backup API or VACUUM INTO, not cp during writes!) and careless placement catastrophic (NFS-class file locking is folklore; local disk or solid understanding of the fact that lock semantics fail over NFS is mandatory).
- The file format's stability is the rare achievement: files written decades ago continue to open for decades more; forensic/research data workflows, config stores, and app caches all benefit from a format that never surprises an update cycle.
- It cannot be presumed small: SQLite powers flight-system avionics and browser-scale caches; practical ceilings usually show up around concurrent write load or HA-requirements, not total data size (beyond cache-boundary terabyte-class operations exist).
- Where the boundary belongs: single-writer analytics, app-local storage, edge devices, prototype-to-production MVP stage; the moment multiple servers or real-time concurrent writers enter the picture, graduate to PostgreSQL or MySQL honestly rather than forcing the format.
Field note
The SQLite file that carried a device fleet for seven years was never the bottleneck, but every backup failure we saw came from cp during writes instead of VACUUM INTO discipline for local-file safety. Correct backups live with the tool, not the distro habit.
Frequently asked questions
Can SQLite run my small website?
Yes, properly designed read-heavy single-box apps do fine; the failure mode is multi-writer load or HA needs, not traffic in itself.
Is it safe on NFS storage?
Often not: file locking semantics over NFS are a documented-local folklore source of corruption. Keep databases on local filesystems.
How do I back it up correctly?
The .backup API/class, or VACUUM INTO a stable file; external tools copy during writes if lock discipline is honored. Never assume cp is atomic during writes.
Is there a real performance ceiling?
Reads scale extremely well (WAL gives concurrent readers), writes serialize at one writer; large deployments survive with WAL plus partitioning patterns or WAL-external scale patterns).
How Kinetikatech helps with databases compared
We've handled this hundreds of times: Database engine choices for hosting workloads, compared on correctness guarantees, operational weight, and real cost: embedded engines against servers, MySQL against PostgreSQL, SQL against document stores, plus the legacy case study that keeps coming back. With Server Management and Website Speed Optimization, you get the full loop, we assess, we implement, we watch it around the clock, and we pick up within 30 minutes when it matters.