OriginChainDB docs
docs · replication · active-active

Multi-region active-active (in development).

IN DEVELOPMENT — NOT YET AVAILABLE

Multi-region active-active is not available for provisioning today. Asking to run a database in this mode is refused when the configuration is installed — it is never accepted and then quietly degraded — and no shipped engine commits any write through consensus. The consensus machinery runs only on engines explicitly configured for engineering drills, the multi-node group this mode needs is still unbuilt, and no date is scheduled. Active-passive replication is the production path for every tenant. This page describes the intended design so you can plan against it; tell us if you need it and we will factor it into how we sequence the work.

Active-active is designed to accept writes in every region you run in and commit them in a single, globally consistent order. Each region would serve both reads and writes locally, with the cluster keeping them in agreement. You would trade a little extra write latency for a stronger durability guarantee on every commit. Everything below describes the intended design for this mode, not behaviour you can buy today, and none of it is scheduled.

What it is designed to do.

  • Writes in every region. Your application would write to its nearest region and read its own writes — no single "write region" to route around. Today there is exactly one writer: every database runs the active-passive path.
  • Stronger durability, on the surfaces it would cover. A committed write would be acknowledged only once a majority of the cluster holds it durably, so an acknowledged write survives the loss of a region. No shipped engine commits a write this way today. The design covers row writes, SQL data changes, Cypher writes, transaction commits and schema registration. It does not yet cover vector index writes, full-text index writes, materialized views, sequence values or geospatial indexes — those are node-local, and closing that gap is a precondition for general availability. It would also cost a little more write latency than single-region active-passive.
  • Failover without moving a write region (roadmap, not built). The intent is that if a region becomes unavailable, the remaining regions keep accepting reads and writes, with no write region to move. No shipped engine does that — it needs the multi-node consensus group described above. Active-passive failover today has a different shape: a provisioned standby tails the writer's stream and can be promoted, and an opt-in automatic promotion path exists. It is off by default, it relies on an external restart hook installed alongside the engine, and it refuses to promote a standby that is not fully caught up. Plan against that shape, not this one.
  • Consistent reads. Reads are designed to reflect the most recently committed state of the cluster, so clients would see a single, coherent view of the data.

When to choose it.

Active-active will be the right choice when writes need to be accepted in more than one region — a globally distributed application where users in different regions all write — or when you want the strongest durability guarantee on every commit and can accept slightly higher write latency in exchange.

If your workload is regional, or sensitive to write latency, the default active-passive setup is faster on the hot path and keeps every byte in the single region you pick. Every database in service runs that path today.

Getting set up.

  • There is nothing to switch on, and no date is scheduled. A request to run a database in this mode is refused when the configuration is installed, and the mode needs a multi-node group per database — not something a running database can be switched into today. If it opens, provisioning and tuning would happen with our team: you pick your regions and durability target, and we configure the cluster for your topology.
  • Before it can carry customer writes, every write surface has to be either replicated across the cluster or explicitly refused; the surfaces listed above are not there yet.
  • If multi-region writes are on your roadmap, tell us now — it helps us sequence the work, and we will be straight with you about timing.