DEV.co
Open-Source Databases · maxpert

marmot

Marmot is a distributed SQLite database server that speaks MySQL protocol, allowing multiple nodes to accept writes simultaneously without a leader. It uses gossip-based replication with tunable consistency levels (ONE, QUORUM, ALL) and automatic conflict resolution via timestamps.

Source: GitHub — github.com/maxpert/marmot
2.8k
GitHub stars
76
Forks
Go
Primary language
MIT
License (OSI-approved)

Key facts

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

FieldValue
Repositorymaxpert/marmot
Ownermaxpert
Primary languageGo
LicenseMIT — OSI-approved
Stars2.8k
Forks76
Open issues5
Latest releasev2.8.0 (2026-01-26)
Last updated2026-05-07
Sourcehttps://github.com/maxpert/marmot

What marmot is

Marmot v2 implements leaderless distributed SQLite replication using 2PC with HLC timestamps, SWIM-style gossip for cluster membership, and CDC-based row-level replication. It transpiles MySQL queries to SQLite, supports distributed DDL with automatic idempotency, and includes vector search (IVF/PQ) for RAG workloads.

Quickstart

Get the marmot source

Clone the repository and explore it locally.

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

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

Best use cases

Distributed WordPress Clusters

Run WordPress across multiple regions with automatic database replication. Each WordPress instance connects to a local Marmot node; schema changes and data replicate cluster-wide without manual intervention.

Edge/Lambda Regional Replicas

Deploy lightweight SQLite replicas at regional edges with local read access. Clients read directly from the SQLite file for maximum performance; writes coordinate via QUORUM consistency to a subset of nodes.

Geo-Distributed Config & Catalog Servers

Fast regional reads of product catalogs or configuration data with eventual consistency. No leader election overhead; any node accepts writes, automatic recovery from network splits via anti-entropy.

Implementation considerations

  • Cluster membership via gossip protocol requires careful network configuration; partition tolerance is achieved via eventual consistency, not strong consensus.
  • Vector search (IVF/PQ) is built-in for RAG but may require tuning for large embedding dimensions and dataset sizes.
  • Media uploads and file storage must use external systems (S3, NFS); Marmot replicates only database changes, not file blobs.
  • Sessions and caching should use Redis/Memcached per region to avoid chat replication and improve local performance.
  • DDL operations acquire distributed locks (30-second default lease); long-running schema changes or node failures during DDL require monitoring.

When to avoid it — and what to weigh

  • Strong Serializability Required — Marmot uses eventual consistency and Last-Write-Wins conflict resolution. If your workload requires strict SERIALIZABLE isolation or distributed ACID guarantees across all nodes, use CockroachDB or Spanner instead.
  • Single-Region High-Throughput Writes — Marmot's gossip-based coordination and 2PC add latency. For single-region, write-heavy transactional workloads, PostgreSQL or MySQL directly are simpler and faster.
  • Datasets Larger Than ~100GB — Marmot replicates the entire database to every node. Horizontal sharding solutions (TiDB, Vitess) are better suited for large distributed datasets requiring partitioning.
  • Requiring Strong Consistency Guarantees — Tunable consistency (ONE/QUORUM/ALL) means writes at ONE consistency can conflict. If linearizability or serializability is mandatory, leader-based systems (Raft, Paxos) are required.

License & commercial use

Marmot is licensed under the MIT License, a permissive OSI-approved license permitting commercial use, modification, and distribution with minimal restrictions (only requiring preservation of copyright and license notices).

MIT License explicitly permits commercial use without royalties or licensing fees. Use in commercial products and services is allowed. Verify compliance with copyright notice requirements and consider obtaining legal review for your specific use case.

DEV.co evaluation signals

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

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceHigh
Security considerations

No security posture or threat model documented. MySQL wire protocol implementation should be validated for injection and protocol attacks. Gossip-based cluster membership is not authenticated by default (requires review). Data at rest is SQLite; consider encryption at rest and in-flight encryption for sensitive workloads. No mention of audit logging, access control lists, or encryption key management.

Alternatives to consider

rqlite

Leader-based SQLite replication using Raft. Simpler failure semantics (no split-brain recovery needed), but requires failover coordination and accepts writes only on the primary.

CockroachDB

Distributed SQL with strong consistency (serializable isolation) and ACID guarantees. Suitable if serializability and horizontal scalability are requirements; heavier operational footprint.

MySQL Active-Active Replication

Battle-tested but requires careful setup (binlog filtering, conflict avoidance), manual failover, and operational expertise. No automatic split-brain recovery; simpler architecture than Marmot.

Software development agency

Build on marmot with DEV.co software developers

Marmot fits edge and regional replication use cases. Start with a single node, test multi-node replication with the provided scripts, and validate against your consistency requirements.

Talk to DEV.co

Related open-source tools

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

Related on DEV.co

Explore the category and the services that help you build with it.

marmot FAQ

Can I run Marmot on a single node in production?
Yes. Single-node deployments skip cluster coordination overhead; replication benefits come when you scale to multiple nodes. Useful for migration from MySQL or local SQLite with future multi-node growth.
What happens if two nodes accept conflicting writes simultaneously?
Last-Write-Wins (LWW) with Hybrid Logical Clock (HLC) timestamps resolves conflicts. The write with the highest HLC timestamp wins; no merge conflict resolution or application-level callback.
Can Marmot replace MySQL for WordPress?
Yes, with caveats. Marmot implements WordPress-required MySQL functions and ON DUPLICATE KEY UPDATE. Media uploads, sessions, and caching require external storage (S3, Redis) because Marmot does not replicate files or transient data.
Does Marmot support sharding?
No. Marmot replicates the entire database to every node. For datasets >100GB or requiring horizontal partitioning, sharded solutions (TiDB, Vitess) are better suited.

Software development & web development with DEV.co

Adopting marmot is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source databases software in production.

Ready to Deploy a Distributed SQLite Cluster?

Marmot fits edge and regional replication use cases. Start with a single node, test multi-node replication with the provided scripts, and validate against your consistency requirements.