marmot: Replicate SQLite Across Distributed Nodes

Overview

Marmot is a distributed SQLite server: applications connect through a MySQL-compatible interface, while nodes replicate database changes using gossip and distributed transactions. Its leaderless design lets any node accept writes, avoiding a single write leader and enabling local reads from SQLite files.

It is aimed at deployments that value lightweight regional databases and availability over strong cross-node consistency. Writes use configurable ONE, QUORUM, or ALL consistency, but the system is eventually consistent rather than serializable across nodes.

Key Features

• MySQL wire protocol support for common clients, drivers, and applications.
• Leaderless replication with gossip-based membership and anti-entropy recovery.
• Distributed transactions with configurable write consistency and per-row conflict resolution.
• Replicated schema changes, multiple databases, and bulk loading with LOAD DATA LOCAL INFILE.
• Optional read-only replicas that discover cluster nodes and fail over between them.
• CDC publishing to Kafka or NATS in a Debezium-compatible format.
• Built-in approximate vector search alongside ordinary SQLite tables.

Use Cases

• Regional WordPress deployments: run an instance against a nearby Marmot node when database changes need to replicate between regions; media files and sessions still need separate handling.
• Edge applications and sidecars: keep SQLite-backed reads close to functions or services, with writes replicated to the wider cluster.
• Read-heavy product catalogs or configuration data: serve local reads across locations when eventual synchronization is acceptable.
• RAG applications: store embeddings with application data and query a local vector index without operating a separate vector service.
• Change-data pipelines: publish database changes to Kafka or NATS for analytics, cache updates, or downstream processing.

Getting Started

Run the server binary, then connect with a MySQL client:

./marmot-v2
mysql -h localhost -P 3306 -u root

See the repository README and project documentation for build instructions, configuration, and cluster setup.

Alternatives

• foundationdb: FoundationDB provides a distributed transactional key-value store, while Marmot replicates SQLite databases and exposes them through the MySQL protocol.

Considerations

• Marmot is eventually consistent. Cross-node operations do not provide strong serializability, and concurrent writes can be resolved per row using last-write-wins rules.
• Every table in a database is replicated. Selective table replication is not supported.
• SQLite must use WAL mode for reliable multi-process changes.
• MySQL protocol compatibility does not mean every MySQL behavior is supported or distributed. For example, user management is local to each node, and table locks are parsed but not enforced cluster-wide.
• Production clusters need operational planning for quorum, network partitions, backups, and cluster authentication. The README recommends configuring a shared cluster secret; authentication is disabled if no secret is set.
• The project documentation describes read-heavy and edge-oriented use, and recommends alternatives when strong serializability, single-region high throughput, or datasets above 100 GB are requirements.