SQLite
| License | FOSS problems | Maintenance | SSO | Users | Tested |
|---|---|---|---|---|---|
| Public DomainPublic domain license. No rights reserved — copyright is waived entirely. No conditions, no attribution required, use it however you want. | — | Active | — | Unlimited | ❌ |
Description
SQLite is a self-contained, serverless, file-based database — the entire engine is a library linked into the application, and the whole database is one file rather than something separate that needs to be run and pointed at. The most widely deployed database engine in the world by unit count, embedded in browsers, phones, and a huge share of software that never advertises using a database at all.
Features
- No separate server process — the whole database is one file, no container, connection string, or network hop between the app and its data.
- WAL mode — real concurrent-read performance, not just single-reader access.
STRICTtables (3.37+) — genuine type enforcement, instead of SQLite's historically loose typing.- Replication tooling — Litestream and LiteFS turn "a file on disk" into continuously replicated, restorable state without a database server to manage.
Usage patterns
- Single-writer workloads — for anything with one process writing to it, dramatically simpler than running Postgres or MySQL alongside a service.
- Multi-writer, edge-replicated territory — forks like Turso's
libSQLpush further into territory that used to be exactly the thing SQLite couldn't do, though still worth checking maturity against the specific need. - Not a Postgres substitute under real multi-writer load — still fundamentally one-writer-at-a-time under the hood; WAL mode takes the edge off light concurrent writes but doesn't replace genuine multi-writer support.
License and governance
Public domain — not merely permissively licensed, no license to comply with at all.
Conclusion
Why you would — dramatically simpler than running a separate database server for anything genuinely single-writer, and it's caught up on the concerns (concurrency, type enforcement, replication) that used to rule it out beyond a toy.
Why you wouldn't — a file next to the app ties its backup story to wherever that file happens to live, without Postgres's decades of tooling around replication, connection pooling, and point-in-time recovery at real scale. The right choice for anything genuinely single-writer, not the default once multiple services need to hit the same data at once.