TL;DR
Marmot v2 is a leaderless, gossip-based distributed replication layer that exposes a MySQL-compatible server while storing data in SQLite. It uses row-level CDC, two-phase commit transactions, and cluster-wide DDL replication with idempotency and configurable consistency levels.
What happened
Marmot v2 introduces a distributed SQLite system that accepts writes on any node and speaks the MySQL wire protocol so existing MySQL clients and tools can connect. The cluster runs a SWIM-style gossip membership and coordinates writes using a two-phase commit implementation with configurable consistency settings (ONE, QUORUM, ALL). Replication uses change data capture at the row level rather than replaying SQL text; row changes are serialized into a binary CDC format and applied deterministically on peers. Schema changes are replicated across the cluster with a distributed locking lease per database and automatic rewriting of many DDL statements for safe replay. Conflict resolution follows a last-write-wins model using hybrid logical clocks. The project also includes an option to publish Debezium-compatible CDC events to sinks such as Kafka or NATS, supports multiple databases per cluster, and provides tools and scripts to start and test multi-node setups.
Why it matters
- Lets applications use familiar MySQL clients while storing data locally in SQLite across a distributed cluster.
- Leaderless write capability removes a single primary node, potentially improving availability and write locality.
- Row-level CDC and Debezium-compatible output simplify building real-time pipelines and integrations with existing tooling.
- Distributed DDL with locking and idempotency reduces schema drift and the risk of conflicting schema changes across nodes.
Key facts
- Leaderless architecture: any node can accept writes; no Raft-style primary required.
- Communication and membership: SWIM-style gossip protocol with failure detection.
- Transaction coordination: two-phase commit (2PC) with configurable consistency modes (ONE, QUORUM, ALL).
- Conflict policy: Last-Write-Wins using hybrid logical clock (HLC) timestamps.
- Replication mechanism: row-level CDC instead of SQL statement replay; binary CDC messages carry column values.
- DDL handling: per-database distributed locks (default lease 30s), automatic idempotent rewrite of many DDLs, and schema version tracking via gossip.
- CDC publishing: can emit Debezium-format events to sinks like Kafka or NATS, supports multi-sink and filtering.
- SQL compatibility: exposes MySQL protocol and supports a broad set of DML, DDL, and database management statements; some session/local admin statements are node-local.
What to watch next
- Real-world production deployments and scale benchmarks — not confirmed in the source
- Security audits and hardening results for the MySQL wire interface and CDC publisher — not confirmed in the source
- Ecosystem integrations and operator tooling (monitoring, backup, upgrades) — not confirmed in the source
Quick glossary
- Gossip protocol: A decentralized method for nodes to share membership and state information by periodically exchanging small messages with peers.
- Change Data Capture (CDC): A replication approach that captures and publishes row-level data changes (inserts, updates, deletes) rather than replaying SQL statements.
- Two-Phase Commit (2PC): A coordination protocol for distributed transactions that first prepares participants and then commits or aborts to ensure atomicity.
- Hybrid Logical Clock (HLC): A timestamping technique that combines physical time with logical counters to order events across distributed systems without strict clock synchronization.
- Debezium: An open-source format and set of conventions for CDC events that many streaming and connector tools recognize for integration with message systems.
Reader FAQ
Can I connect with existing MySQL clients and tools?
Yes. Marmot exposes a MySQL-compatible wire protocol so clients like mysql CLI, DBeaver, and MySQL Workbench can connect.
Does Marmot require a single primary node for writes?
No. The system is leaderless and allows writes on any node; it uses gossip and 2PC to coordinate writes.
How are schema changes handled across the cluster?
DDL operations acquire a distributed lock per database, are rewritten for idempotency where possible, and are replicated through the same transaction mechanism.
Does Marmot replicate SQL statements or row changes?
It replicates row-level changes via CDC messages rather than replaying SQL text.
Is Marmot production-ready and battle-tested?
Not confirmed in the source
Marmot v2 What & Why? Marmot v2 is a leaderless, distributed SQLite replication system built on a gossip-based protocol with distributed transactions and eventual consistency. Key Features: Leaderless Architecture: No…
Sources
- Marmot – A distributed SQLite server with MySQL wire compatible interface
- Marmot V2 – Distributed SQLite Replicator – Nextra
- A distributed SQLite server with MySQL wire compatbility
- Marmot: A distributed SQLite replication
Related posts
- Using WebAssembly to Build Python Extension Modules Without Native Toolchains
- Can Bundler Match uv’s Speed? Analyzing Bottlenecks and Fixes
- Exploring Whether Bundler Can Match uv’s Package Installation Speed