# FrankenSQLite: a Rust SQLite reimplementation with page-level MVCC writers

> FrankenSQLite rewrites SQLite in safe Rust and replaces the single write lock with page-level MVCC. The compatibility runtime over standard SQLite files is the part that actually runs today; the concurrent-writer and RaptorQ durability claims are not yet wired into the live commit path.

**Dicklesworthstone/frankensqlite** — Independent ground-up Rust reimplementation of SQLite with concurrent writers and information-theoretic durability

- Repository: https://github.com/Dicklesworthstone/frankensqlite
- Stars: 240 · Forks: 46
- Language: Rust
- License: NOASSERTION
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/dicklesworthstone-frankensqlite

## The single-writer lock FrankenSQLite is trying to remove

SQLite serializes writers through one lock byte. The README names it directly: WAL_WRITE_LOCK at wal.c:3698. Every write transaction queues behind that byte, so adding cores does not raise write throughput on a write-heavy workload. The project also points at two failure modes it wants to address: torn writes and bit-flips that corrupt a database with no self-repair mechanism.

The audience is narrow and specific. This is for Rust teams embedding a database who have hit the write ceiling and would rather not run a server process to escape it. It is not aimed at people who want a drop-in replacement for the sqlite3 binary tomorrow, because the README is explicit that the runnable engine is still hybrid.

## Page-level MVCC, SSI, and what is actually live

The design choice is page granularity. Row-level versioning, in the README's framing, would break the file format and require VACUUM. Table-level versioning would conflict on every write to a shared table. Pages map onto SQLite's B-tree, so writers touching different leaf pages can do page-version work at the same time.

That concurrency is bounded. Commit validation and publication still contain coordinated sections, and transactions can abort and retry because of Serializable Snapshot Isolation dependencies or structural B-tree overlap. SSI tracks write-skew dependencies by default. A write-merge ladder (intent replay plus structured page patches) exists in the tree but the README states it is dormant and tested implementation work, not wired into the live commit path, so same-page base drift currently aborts and retries.

The workspace layout matches that story. Cargo.toml lists separate crates for fsqlite-pager, fsqlite-wal, fsqlite-mvcc, fsqlite-btree, fsqlite-parser, fsqlite-planner and fsqlite-vdbe, with the engine core in fsqlite-core and the CLI in fsqlite-cli. Unsafe code is forbidden at the workspace level; only fsqlite-vfs (mmap and shared memory) and the optional fsqlite-c-api FFI shim override that locally. If you use the Rust crates or the CLI, the README says you never need the C ABI shim.

## Installing the fsqlite CLI and opening a real database

The README gives a shell installer for Linux and macOS that selects a native release artifact, requires its SHA-256 entry, and authenticates the signed checksum manifest when minisign is available. It runs exact-version and SQL smoke tests before reporting success. Linux artifacts are fully static, so the same download works on glibc and musl distributions.

```bash
curl -fsSL "https://raw.githubusercontent.com/Dicklesworthstone/frankensqlite/main/install.sh?$(date +%s)" | bash
```

Windows users get an equivalent PowerShell path:

```powershell
irm "https://raw.githubusercontent.com/Dicklesworthstone/frankensqlite/main/install.ps1?$([DateTime]::UtcNow.Ticks)" | iex
```

Rust users can skip the installer entirely. The README documents a Cargo route with a locked dependency graph:

```bash
cargo install fsqlite-cli --locked
```

One boundary matters before you point it at anything. In the v0.2.0 compatibility runtime, the database text encoding must be encoding 1 (UTF-8). Valid UTF-16le and UTF-16be headers are recognized and rejected rather than decoded or rewritten. So the first real test is opening a copy of an existing UTF-8 database and confirming the engine reads it. The repository ships sample_sqlite_db_files/ and a conformance/ directory, which is where to look for fixtures rather than generating your own.

The installer has its own caveats worth reading before you pipe it into a shell: install.sh --help and Get-Help ./install.ps1 -Detailed document exact-version pinning, air-gapped installs, custom destinations, source builds and post-install verification. Prebuilt installer support covers v0.1.16-v0.1.17 and resumes with v0.2.0; the README states v0.1.18-v0.1.19 did not publish native signed artifact sets.

## Where FrankenSQLite is the wrong tool right now

The honest reading of the README is that the headline feature is not shipping. The comparison table itself says concurrent writers are "many by design" but notes the v0.2.0 candidate remains blocked on concurrent-writer correctness gates. If your reason for considering this project is write concurrency, the live path does not deliver it yet.

Durability has the same shape. The README states plainly that the v0.2.0 compatibility WAL commit and recovery path neither writes nor consults RaptorQ repair symbols, and that the live runtime does not justify a blanket self-healing or numeric durability claim. The RaptorQ and ECS sections describe design plus partial implementation gated on end-to-end recovery evidence.

Encryption is another gap. XChaCha20-Poly1305 DEK/KEK code exists in fsqlite-pager, but no PRAGMA key or rekey dispatch is wired into Connection, so page-level encryption is not available. SQL coverage is a subset: the README says parser coverage exceeds full execution parity, and extension crates for FTS3, FTS5, R-tree, JSON, session, ICU and misc are present with some runtime wiring still in progress. If you depend on a specific extension at query time, verify it against supported_surface_matrix.toml before you plan around it.

## How this differs from Turso and from C SQLite

Turso is the obvious comparison point, and the difference is architectural rather than cosmetic. FrankenSQLite keeps the SQLite 3.x file format as a non-negotiable goal for encoding 1 databases and puts its concurrency work at page level inside that format, so existing .db, rollback-journal and WAL files stay the unit of storage. A rewrite that changes the on-disk format buys freedom at the cost of every existing tool that reads SQLite files.

Against C SQLite itself, the split is memory safety and lock granularity. The engine, pager, parser and VDBE stay in safe Rust by workspace lint, with unsafe confined to the VFS and the optional C API shim. C SQLite is the reference implementation and remains the thing FrankenSQLite is measured against: the repository carries legacy_sqlite_code/, a parity_score_contract.toml, a parity_taxonomy.toml and conformance/ fixtures, which tells you the project treats behavioral parity as an ongoing score rather than a finished state.

## Licence, upgrade cost, and what the version numbers tell you

The licence is the thing to read first. Cargo.toml sets license-file = "LICENSE" and the comment above it describes the terms as "MIT License (with OpenAI/Anthropic Rider)", a restrictive custom licence with no rights to OpenAI or Anthropic and no ML training or evaluation use. It is not an SPDX expression and not permissive MIT, which matters if your organisation scans licences automatically or if you plan to train models on the code. That is a description of the file, not legal advice; read LICENSE yourself.

Upgrade cost is real but bounded by the crates split. The workspace pins edition 2024, carries a rust-toolchain.toml, and enforces pedantic and nursery Clippy lints at deny level, so building from source ties you to a recent toolchain. The repository also keeps UPGRADE_LOG.md and CHANGELOG.md at the top level, which is where release-to-release breakage is recorded.

Release cadence is fast: v0.3.9, v0.3.10 and v0.3.11 all landed within four days in late August 2026, and the last push to main was on 2026-08-27. Rapid point releases on a 0.x line mean the surface you build against can move. If you vendor the CLI, pin an exact version through install.sh rather than tracking main.

## Conclusion

Adopt FrankenSQLite today only if you want a Rust-native engine that reads and writes ordinary SQLite files with encoding 1 (UTF-8), and you are willing to treat it as a moving target. Do not adopt it expecting many concurrent writers or self-healing storage: the README states the write-merge ladder is dormant, same-page base drift aborts and retries, and the compatibility WAL path neither writes nor consults RaptorQ repair symbols. Before committing, check the LICENSE file for the OpenAI/Anthropic rider, confirm your databases are UTF-8 rather than UTF-16, and read supported_surface_matrix.toml to see which SQL surface is actually wired up.

## FAQ

### What is a good Rust alternative to SQLite?

FrankenSQLite is a ground-up Rust reimplementation of SQLite that keeps the SQLite 3.x file format for encoding 1 (UTF-8) databases, so it can open standard .db files. Its engine, pager, parser and VDBE stay in safe Rust, with unsafe limited to the VFS and the optional C API shim.

### Does FrankenSQLite support concurrent writers?

Page-level MVCC is the design, and writers touching different pages can overlap their page work, but commit validation and publication still contain coordinated sections. The README states the v0.2.0 candidate remains blocked on concurrent-writer correctness gates, and the write-merge ladder is dormant rather than wired into the live commit path.

### Can FrankenSQLite open an existing SQLite database file?

Yes, compatibility mode over standard SQLite files is the live runtime path. One boundary applies in v0.2.0: the database text encoding must be encoding 1 (UTF-8). Valid UTF-16le and UTF-16be headers are recognized and rejected rather than decoded or rewritten.

### How do I install the FrankenSQLite CLI?

The README gives a curl-to-bash installer for Linux and macOS and an irm-to-iex installer for Windows PowerShell, both of which verify a SHA-256 entry and authenticate the signed checksum manifest when minisign is present. Rust users can instead run cargo install fsqlite-cli --locked.

### Does FrankenSQLite provide self-healing storage?

Not in the live runtime. The README states the v0.2.0 compatibility WAL commit and recovery path neither writes nor consults RaptorQ repair symbols, and that the RaptorQ and ECS material is design plus partial implementation gated on end-to-end recovery evidence.

## Sources

- [Official README](https://github.com/Dicklesworthstone/frankensqlite#readme)
- [Project repository](https://github.com/Dicklesworthstone/frankensqlite)
- [Release notes](https://github.com/Dicklesworthstone/frankensqlite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dicklesworthstone-frankensqlite