ADR 0008: orbit-rs is adopted for hosted data only after an exit gate passes

ADR 0008: orbit-rs is adopted for hosted data only after an exit gate passes

Status: Accepted Date: 2026-10-23 Scope: Symphony Deciders: Ravindra Boddipalli

Context

Hosted Symphony runs one container with SQLite files restored from R2 on every start, which loses the last seconds of writes on a crash and cannot reach 1000+ organizations. The proposed fix is a replicated database tier. orbit-rs, the project’s own Rust database, was measured against Symphony’s install plan and eight flow cases on 2026-10-23: from 0 of 8 to 8 of 8 flows, 3360 of 3360 install statements, surviving kill -9, and passing on a three-node cluster through a leader kill. Open at that date: write tail latency (3-node p95 about 1.7x and p99 about 5x PostgreSQL’s), the data set must fit in RAM, reads scan.

Decision

orbit-rs stays a candidate. PostgreSQL stays the production path until orbit-rs write p95 is at parity with PostgreSQL and a sustained soak and chaos run on a three-node cluster passes. Tenant databases cannot use orbit-rs until ADR 0009 is accepted and implemented (open_tenant currently opens every tenant as SQLite).

Consequences

• No hosted tenant is migrated to orbit-rs before the gate; documents do not describe orbit-rs as a replacement already in use.
• The app tier (stateless, ephemeral containers) and the data tier (long-lived nodes with persistent volumes) are separate; orbit-rs nodes do not run on an ephemeral disk.

Canonical wording

orbit-rs is a candidate for Symphony’s hosted data tier. PostgreSQL remains the production path until orbit-rs passes the exit gate (write p95 at parity and a passing soak run).

Verification

cargo test -p symphony-postgres --test orbit and --test orbit_flows with SYMPHONY_ORBIT_URL; the cluster and latency results in DATA_DURABILITY.md.