Mikedan37/BlazeDB
LibraryLive in productionEmbedded, encrypted, single-process. A document database for Swift with ACID transactions, WAL-backed crash recovery, and AES-256-GCM at rest. One encrypted fil
Swift-native embedded database for local app storage with encrypted page persistence, WAL-backed crash recovery, and reactive SwiftUI integration.
- Swift98.0%
- Python1.3%
- Shell0.8%
- Dockerfile0.0%
1 Review
BlazeDB is an ambitious Swift database project with a much stronger onboarding story than I expected from a young, low-signal repository. The README does a good job narrowing the mental model early: one encrypted file, embedded in-process storage, typed Swift models through BlazeStorable, and a simple open / put / get / query flow. The Examples/HelloBlazeDB/main.swift sample mirrors that path cleanly, which is exactly what a database library needs: a maintainer can evaluate the API shape in a minute without first understanding the storage engine.
The strongest part of the repo is the engineering discipline around compatibility and testing. Package.swift shows a deliberate split between BlazeDBCore, the umbrella BlazeDB target, CLI tools, examples, benchmarks, and tiered test targets. The CI setup is also unusually thoughtful: PR checks cover macOS build/CLI/Tier0/Tier1 plus Linux core/Tier0, while deeper nightly and weekly lanes are documented in Docs/Testing/CI_AND_TEST_TIERS.md. That gives the project more credibility than the current 0-star / 0-fork community signal suggests.
The main adoption risk is that some messaging is ahead of the default runtime. The README is careful now about “not distributed sync,” while the repository description still advertises distributed sync and server-ish capabilities. I’d align the GitHub description with the current supported surface: embedded, encrypted, Swift 6, ACID/WAL, CLI tools. The compatibility doc also says distributed modules are not Swift 6 compliant yet, and the shim explicitly leaves distributed imports disabled, so that gap should stay visible.
For maintainers evaluating BlazeDB, the next improvements I’d prioritize are a short architecture diagram for storage/WAL/encryption boundaries, a “production readiness” section explaining single-process limits and recovery guarantees, and published benchmark numbers with hardware/toolchain details. The MIT license, SwiftPM support, examples, and CI discipline are all good foundations; tightening the public claims around what is stable today would make the project easier to trust and adopt.
