Comparison
In the table, every statement about another product is a quotation from that vendor's own documentation, with a link and the date it was read. The notes on Turso and Rivet are our own description, with a link to theirs. Nothing here was measured against a competitor. Products change: follow the links before you rely on a row.
How to read this. Vendor statements were read on 12 November 2026. Gauntlet rows describe pre-beta software; its limits apply. Where Gauntlet is behind, this page says so.
The precise claim is isolation as well as atomic commit across shards. It is not "other systems have no distributed transactions".
| System | Atomic commit across shards | Isolation across shards | Source |
|---|---|---|---|
| Gauntlet Pre-beta | Yes. Prepare on each shard, one write-once decision object, then resolve. | Strictly serializable. It is the default and the only mode. | Transactions |
| Vitess 24, mode Multi (the default) | "Can span multiple shards with best-effort commits." Guarantee listed as "No atomicity". | Not offered in this mode. | Vitess docs |
| Vitess 24, mode TwoPC | "Atomic commits across multiple shards." | "It does not provide isolation in the traditional ACID sense." "Applications might observe fractured reads in a cross-shard query." | Vitess docs |
| PlanetScale Neki | "Neki commits each shard separately. It does not use two-phase commit to make every shard succeed or fail together." "Distributed and atomic cross-shard transactions are not yet supported." | "An ordinary multi-shard read does not establish one shared Postgres snapshot across its destinations." | Neki docs |
Single-shard transactions in Vitess and Neki are ordinary MySQL and Postgres transactions; the rows above are about transactions that touch more than one shard. Both systems let you restrict a session to one shard.
Gauntlet runs Turso's SQL engine, so the dialect is the same family. The storage is different: Gauntlet uses its own bucket-backed storage and none of Turso's own (its indexes, full-text search, vector index and change capture are not available in Gauntlet). Turso offers embedded replicas and sync for local-first applications. Gauntlet is a server only: a write made offline cannot be strictly serializable against the bucket.
A different category: durable actors with state attached to compute, and SQL used from code running inside the actor. Gauntlet is a database you connect to over a wire protocol from anywhere, with transactions across the shards of a database. If your state belongs to one long-lived actor, look at Rivet. If many services share SQL state and need one order of transactions, that is Gauntlet's case.
A comparison that lists only wins is an advertisement. These are true today.
| Area | Gauntlet today |
|---|---|
| Maturity | Pre-beta. Its own acceptance run has not passed. The systems above run production workloads. |
| Write latency | Every commit waits for conditional writes to an object store. A database that acknowledges on local disks is faster per write. |
| Schema changes | A table cannot change. No ALTER TABLE, CREATE INDEX or DROP TABLE. |
| Ecosystem | No certified ORM, no SDK, no PostgreSQL SQL, no managed service. |
| Storage | Nothing is reclaimed. The bucket only grows. |
| Recovery and branching | Whole-image backups only. No point-in-time restore and no branches. |
| Access control | One token per database. No roles. |
| Independent evidence | None. The correctness evidence is the project's own tests, simulation and models. |
The plan to close these gaps is the roadmap.