SQLite
otsumami.sqlite
A Docker Compose file for SQLite alone, generated from the catalog and checked by the safety inspector. No account needed.
Embedded relational database that stores an entire database in one file and runs inside the calling process, with no server, configuration or administration to manage.
SQLite implements most of SQL in a small library linked into the application, so a database is a single portable file rather than a service with credentials and a network address. Transactions are ACID and survive process and power failure, which is what makes it the default store for application configuration, local caches and single-writer workloads. Its file format is long-term stable and explicitly committed to backwards compatibility, so a file written today opens in builds many years apart. The container here supplies the command-line shell for inspecting and manipulating those files directly.
You know it worked when
- The shell opens a database file and reports its version.
- A table can be created, written to and read back.
- The database file is present on the mounted volume after the shell exits.
- That file reopens intact from a new container.
Known sharp edges
- It is a library and shell rather than a service, so a container started without a command exits immediately and there is nothing to connect to over a network.
- Only one writer can hold the database at a time, and concurrent writes from separate containers produce lock errors rather than queuing.
- The default journal mode gives poor concurrency, and write-ahead logging must be enabled deliberately for read-during-write workloads.
- A database file on a network or overlay filesystem can have its locking silently ignored, which corrupts the file rather than reporting an error.