SeriousDB is a dictionary with crash recovery
SeriousDB puts a module-level key-value API in the same Python process as your application. The first operation loads a local .sdb JSON snapshot into a dictionary. Reads come from memory. Each set or delete updates that dictionary and appends a record to .sdb.wal, flushing and syncing the entry before returning. After enough writes, compaction replaces the snapshot atomically and clears the log.
That design solves a narrow problem well: a script can keep durable state without starting Redis or writing file-replacement logic. Version 0.2.2 needs Python 3.11 or newer and declares one runtime dependency, python-dotenv. The public API includes individual and bulk reads, existence checks, counts, writes, deletes, and an explicit load path. There is no server to secure and no connection string to rotate.
The 64-file codebase is easy to inspect
Our measured checkout had 64 files, about 3,843 lines of source, and occupied 0.3 MB before installation. The architecture guide can explain the whole call path in a few paragraphs because the moving parts are api.py, a Cache, a Python dictionary, a snapshot, and the write-ahead log. That is attractive for learning, auditing, or contributing to persistence code without first mapping a large engine.
Small also means exposed. There is no query planner, index manager, remote protocol, or background server between your application and the data structure. The complete data set resides in memory once loaded. A local tool with hundreds or thousands of small values may find that convenient. An application whose data already strains RAM has crossed the boundary this design sets.
What happened when we ran it
Our sandbox installed commit af58a0c in 29 seconds. The installation added 37 packages and occupied 37 MB on disk. We used an unprivileged Debian container with Python 3.12, 3 CPUs, 8 GB of RAM, and no secrets. The repository contained a tests directory and 5 CI workflow files, but no Dockerfile.
The package build succeeded in 6 seconds. Pytest took 664 seconds and reported 182 passed with 0 failed. Pip-audit found 0 known vulnerabilities in the installed environment. These results verify packaging, the supplied test suite, and the audited dependency set at commit af58a0c. They do not measure database throughput, crash recovery under power loss, or behavior with a production-sized file.
The test duration is unusual beside a 6-second build, yet the result was complete rather than timed out. We did not invent a speed comparison from that run. SeriousDB's vision document names TinyDB as its intended practical comparison and describes future direct-engine benchmarks, but our sandbox facts cover installation, build, tests, and dependency auditing only.
One process owns the writable file pair
SeriousDB uses an in-process lock. Separate processes load separate dictionaries and own separate locks, even if they point at the same .sdb and .sdb.wal files. The persistence guide says concurrent writes and multi-process access are not coordinated. Issue 247 gives the concrete failure: one process can compact its older in-memory state, overwrite the snapshot, and wipe another process's logged write.
This rules out common deployment shapes such as 4 web workers writing one database path. It also complicates cron jobs that touch the same file while the main program runs. A single process with internal threads stays inside the documented model, though issue 269 notes that all reads currently pass through one exclusive lock. Teams reaching for worker pools should choose storage with process-level coordination.
Each successful write is durable, but groups are not atomic
The write-ahead log improves the failure story for one operation. SeriousDB syncs each log record before reporting success, replays valid records on startup, and stops at an incomplete final record. Snapshot replacement uses a temporary file and rename. Those are meaningful safeguards for a compact local store.
A transfer between 2 account keys still needs more. Open issue 285 explains that each write commits independently, so a crash between the debit and credit leaves inconsistent data. The current API has no multi-key transaction or rollback boundary. That gap is harmless for an isolated preference value and unacceptable for balances, inventory, or any invariant spanning records.
Backups have a related limitation. Issue 248 asks for an atomic backup method because copying the snapshot while writes continue may produce an unsafe result. Until the project supplies and documents that path, stop the writer before copying both files or use a database with online backup support.
The storage engine is still being redesigned
Release 0.2.2 shipped on September 25, 2026, and the repository was pushed on September 30. GitHub showed 292 stars, 12 open issues, and 21 combined issues and pull requests. Five CI workflows plus the 182-test result show real engineering attention for a young package.
The same activity signals change rather than settled compatibility. The package metadata labels the project alpha. RFC 290 says the single serialized file does not scale well and proposes a directory layout with B-tree indexes and WAL segments. Pull request 310 begins a 4 KiB page format for that engine. Those are early implementation moves, not a promise that the current file format will stay fixed.
SeriousDB is easy to understand because its boundary is honest and small. For a single-process utility, its 37 MB installed environment and green 182-test run make a trial reasonable. If your data matters across processes or across related keys, its own docs and issue tracker already point you elsewhere.