DEV.co
Open-Source Databases · losfair

mvsqlite

mvSQLite is a distributed database that layers SQLite on top of FoundationDB, enabling multi-version concurrency control (MVCC) and time-travel queries without the traditional locking overhead. It lets you use standard SQLite APIs while gaining distributed transaction guarantees, horizontal read scalability, and the ability to query historical snapshots of your data.

Source: GitHub — github.com/losfair/mvsqlite
1.6k
GitHub stars
47
Forks
Rust
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositorylosfair/mvsqlite
Ownerlosfair
Primary languageRust
LicenseApache-2.0 — OSI-approved
Stars1.6k
Forks47
Open issues33
Latest releasev0.3.22 (2026-04-30)
Last updated2026-06-25
Sourcehttps://github.com/losfair/mvsqlite

What mvsqlite is

mvSQLite implements a custom VFS layer for SQLite that routes I/O to FoundationDB, providing MVCC semantics via FoundationDB's versioned key-value store. It removes FoundationDB's five-second transaction limit, supports lock-free concurrency akin to BEGIN CONCURRENT, and exposes experimental cross-database commit groups for multi-database atomicity.

Quickstart

Get the mvsqlite source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/losfair/mvsqlite.gitcd mvsqlite# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Time-travel queries and audit trails

Applications requiring historical snapshots or audit logs can checkout database state at any past timestamp, eliminating the need for separate audit tables or time-series databases.

Read-heavy distributed systems with scaling requirements

Lock-free reads and FoundationDB's replication enable horizontal scaling of read workloads across multiple nodes without distributed lock contention, suitable for analytics and reporting.

Multi-tenant systems with strong consistency

Leverage FoundationDB's ACID guarantees and mvSQLite's MVCC to serve multiple tenants with isolated, consistent databases while maintaining operational simplicity via SQLite compatibility.

Implementation considerations

  • FoundationDB cluster setup, configuration, and operational knowledge are prerequisites; mvSQLite does not abstract away FDB complexity.
  • Integration via LD_PRELOAD requires a custom or patched libsqlite3; standard system SQLite binaries will not work due to static linking.
  • Experimental features (commit groups) should not be used in production without thorough validation and understanding of their serialization limitations.
  • Binary releases are provided for x86-64; other platforms require building from source using Rust toolchain.
  • Namespace creation and metadata management are handled via admin API; plan for initialization automation and lifecycle management.

When to avoid it — and what to weigh

  • You require standalone, single-node deployments — mvSQLite mandates a FoundationDB cluster; there is no single-node fallback mode. If you need embedded SQLite without external dependencies, this is not suitable.
  • You need production-ready cross-database transactions — Commit groups are marked experimental and do not provide cross-database serializability for read-dependent invariants. Standard multi-DB transactions will not be safe until stabilized.
  • Your workload has frequent long-running transactions — While mvSQLite removes the five-second limit, very long transactions may still face conflicts under high write concurrency. FoundationDB's conflict detection applies per-database.
  • You operate in environments where FoundationDB is unavailable or unsupported — FoundationDB availability and operational maturity in your target environment is a hard dependency. If FoundationDB is not viable, mvSQLite cannot be deployed.

License & commercial use

mvSQLite is licensed under Apache License 2.0 (Apache-2.0), a permissive OSI-approved license.

Apache-2.0 permits commercial use, modification, and distribution under standard OSI terms (retain attribution and license notice). However, commercial viability depends on your FoundationDB deployment model—if FoundationDB itself is self-hosted, review any additional licensing or support agreements you may have with Apple or third-party FoundationDB providers. Requires review if you plan to embed or redistribute mvSQLite as a closed-source component.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityHigh
DEV.co fitPossible
Assessment confidenceMedium
Security considerations

mvSQLite's security posture inherits from FoundationDB's implementation (encryption at rest/in transit, authentication, access controls). However, no explicit security audit, vulnerability disclosure process, or threat model documentation is provided in the README or repo metadata. The custom VFS layer and FoundationDB integration surface introduce complexity; review FoundationDB's security documentation and conduct threat modeling for your threat model. LD_PRELOAD integration may present privilege escalation risks if not carefully controlled in multi-tenant environments.

Alternatives to consider

PostgreSQL (with time-series or archive tables)

Mature, widely deployed alternative for distributed systems; time-travel requires application-layer audit logic or custom versioning. Simpler operational model but lacks native MVCC snapshot querying.

CockroachDB

Distributed SQL database with ACID guarantees, time-travel via AS OF SYSTEM TIME, and no external dependencies. Higher resource overhead and query optimizer complexity, but comprehensive documentation and commercial support.

DuckDB with Delta Lake / Iceberg

Lightweight, embeddable SQL engine with versioning and time-travel via Delta/Iceberg table formats. Suitable for OLAP workloads; lacks MVCC for OLTP and requires separate object storage.

Software development agency

Build on mvsqlite with DEV.co software developers

mvSQLite offers powerful distributed semantics but demands FoundationDB expertise and operational complexity. Assess your team's FoundationDB maturity, isolation requirements, and tolerance for experimental features before committing to a pilot.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

mvsqlite FAQ

Do I need to modify my application code to use mvSQLite?
Minimal or no changes needed if you use standard SQLite APIs. LD_PRELOAD integration allows drop-in replacement; custom SQL extensions or pragma directives unsupported by the VFS layer will require adaptation.
Can I run mvSQLite without FoundationDB?
No. FoundationDB is a hard dependency; mvSQLite is a layer on top of FDB's key-value store and cannot operate standalone.
Is commit groups safe for production cross-database transactions?
No. Commit groups are experimental and do not provide cross-database serializability. They are suitable only for 'all-or-nothing' workflows (e.g., debit/credit) where isolation between databases is acceptable.
What are the performance characteristics compared to standard SQLite?
Unknown. No benchmarks provided in the repo. Distributed coordination overhead and FoundationDB's latency will differ from local SQLite; performance depends on your workload, network, and FDB cluster configuration.

Software developers & web developers for hire

DEV.co helps companies turn open-source tools like mvsqlite into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source databases stack.

Evaluate mvSQLite for Your Architecture

mvSQLite offers powerful distributed semantics but demands FoundationDB expertise and operational complexity. Assess your team's FoundationDB maturity, isolation requirements, and tolerance for experimental features before committing to a pilot.