Skip to main content

Open-source distributed SQL database

CamusDB logo

The SQL database that scales itself

Write ordinary SQL. CamusDB spreads it across a cluster that scales writes, survives node failures, and runs transactions at Serializable isolation by default — no sharding, no eventual-consistency surprises.

Start the tutorialWhy CamusDB?
Scales writes across nodesNo manual sharding — data is partitioned for you.
Stays online through failuresRaft replication keeps the cluster serving when a node drops.
Strong transactional guaranteesSerializable transactions, committed reads, and atomic writes.
CREATE DATABASE IF NOT EXISTS shop;
use shop;

CREATE TABLE orders (id OID PRIMARY KEY, sku STRING, qty INT64);

BEGIN;
  UPDATE stock SET qty = qty - 1 WHERE sku = "A-100";
  INSERT INTO orders VALUES (GEN_ID(), "A-100", 1);
COMMIT;  -- serializable across the whole cluster

SQL without manual sharding

Define tables and indexes, then query with joins, subqueries, derived tables, grouping, ordering, and pagination.

Serializable by default

Protect application invariants with serializable transactions by default and two-phase commit for cross-partition writes.

Multi-active cluster

Send traffic to multiple nodes while Raft-backed partitions elect leaders and replicate committed writes.

Why distributed NewSQL?

Built beyond the single-primary model

CamusDB keeps the familiar relational workflow while moving storage, replication, and transaction coordination into a distributed cluster.

Traditional databases

  • A single primary node often becomes the write bottleneck.
  • Failover can require promotion, reconnection, and operational intervention.
  • Scaling writes commonly means manual sharding or application-side routing.
  • Lower isolation levels can expose concurrency anomalies unless the app compensates.

CamusDB

  • Multiple nodes can accept client traffic while partitions route writes to their leaders.
  • Raft consensus elects leaders per partition and replicates committed writes.
  • Data is partitioned across the cluster instead of tied to one process.
  • Atomic distributed writes use two-phase commit, with Serializable as the default isolation level.

Consistency model

Why strong consistency matters

Distributed databases do not all make the same correctness tradeoff. CamusDB is designed around strongly consistent committed state instead of eventual convergence as the default application model.

Strong consistency

  • Reads observe committed state instead of waiting for replicas to catch up.
  • Applications can enforce invariants without stitching around stale reads.
  • Failover does not silently trade correctness for temporary divergence.
  • Transactions and constraints stay meaningful across nodes, not just on one machine.

Eventual or weaker consistency

  • A read can return older data even after another client committed a write.
  • Conflict resolution often moves into application code and background repair.
  • Cross-row or cross-entity business rules become harder to enforce safely.
  • Operational simplicity at the storage layer can become correctness complexity in the app.

Practical example: one item left in stock

Two buyers place an order for the last available item at nearly the same time. With stale reads or eventually consistent replicas, both requests can see stock available and both can try to commit, forcing the application to repair oversold inventory later.

  • With Serializable isolation by default, one order commits and the conflicting transaction retries.
  • The database protects the inventory invariant instead of leaving oversold stock to asynchronous repair.
  • The application logic stays simpler because correctness does not depend on reading from the “right” replica.