It seems like SQLite has shown up in more places everywhere you look.
SQLite is an implementation of a SQL database engine as a C-language library. That means SQLite can be embedded into binaries, run in the browser, on edge devices, or anywhere else.
- I'm all-in on server-side SQLite (5-9-22)
- JSON and Virtual Columns in SQLite
- Wp-SQLite: WordPress running on an SQLite database
- Sqldiff: SQLite Database Difference Utility
- High-Availability SQLite
- Ask HN: Have you used SQLite as a primary database?
SQLite has been around since 2000, so why now? In an era where most databases are managed services in the cloud, why go through the trouble of using something else?
Serverless. SQLite is serverless in the literal sense of the word. No server process manages the database – if you want to access the database, you read or write directly from the database files on disk.
Edge. SQLite shines in edge use cases – sometimes as simple as storing configuration. It's lightweight and provides an embeddable SQL interface for edge deployments.
Browser-compatible. With WebAssembly, the browser is the new runtime. As more complex and compiled applications run in the browser, they will have data and configuration requirements: no network stack, no problem for SQLite.
For some classes of applications (e.g., blogs), the network has become the limiting factor in page load. For heavy-read and mostly static data, the cost of maintaining a little bit of state on the edge is low enough to push the data layer up. It's a similar trend to the shift toward client-managed state and server-managed state in frontend frameworks.
There's no silver bullet. I'm skeptical of widespread adoption of distributed layers over SQLite (e.g., BedrockDB and Litestream) for applications that are state-heavy. As SQLite deployments scale, I imagine they will face the same issues that have been solved for years by PostgreSQL and other well-trodden SQL databases. It's a complexity trade-off in different parts of the stack.