Multi-region active-active (in development).
Multi-region active-active is not available for provisioning today. The underlying replication layer is built and tested, but it is deliberately not enabled in any shipped engine until its durability proof is signed off, so no instance you can run right now commits writes through it. Active-passive replication is the production path for every tenant. This page describes the design so you can plan against it; talk to us if you need it and we will scope the timeline with you.
Active-active will accept writes in every region you run in and commit them in a single, globally consistent order. Each region serves both reads and writes locally; the cluster keeps them in agreement automatically. You trade a little extra write latency for a stronger durability guarantee on every commit and seamless failover if a region goes dark. Everything below describes the designed behaviour, not behaviour you can buy today.
What you get.
- Writes in every region. Your application can write to its nearest region and read its own writes — no single "write region" to route around.
- Stronger durability, on the surfaces it covers. A committed write is acknowledged only once a majority of the cluster holds it durably, so an acknowledged write survives the loss of a region. That 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 also costs a little more write latency than single-region active-passive.
- Automatic failover. If a region becomes unavailable, the remaining regions keep accepting reads and writes with no manual intervention; the cluster is read-write within seconds.
- Consistent reads. Reads reflect the most recently committed state of the cluster, so clients 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. Most tenants should stay there.
Getting set up.
- There is nothing to switch on yet. When it opens, provisioning and tuning will 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.