How OriginChain works under the hood.

One AI-native database. One log. Atomic commits.

The storage layer is a single key-value store. Every key is a 16-byte BLAKE3 prefix over its logical identity; every value is a length-prefixed, CRC32C-framed blob. The index lives in memory for O(1) lookup, the data lives on disk as packed columnar chunks, and a write-ahead log is the single source of truth. Group commit merges concurrent writes into one fsync per window so write throughput scales with vCPU instead of bottlenecking on a single core.

Each managed instance runs on its own EC2 box, its own VPC, its own EBS volume, its own TLS certificate. Tenancy is physical, not logical — there is no shared load balancer, no shared disk, and no shared memory between customers. A managed box in eu-west-1 sends bytes only to eu-west-1, so data residency is structural rather than configurable.

Ten shapes. One vector database. One graph. One full-text index.

Domain-prefixed keys give OriginChain atomic writes across every derived structure your data needs. Schemas, rows, secondary indexes, forward and reverse edges, BM25 postings, vectors, HNSW graphs, and columnar chunks all live in the same hash-keyed store under a different domain tag. The 16-byte hashed prefix makes each layer enumerable by prefix scan; the suffix makes each entry unique. Add a vector column or a relation and your write path stays one batch — no sidecar engine, no double-bookkeeping, no eventual-consistency window between your row and its index.

One plan tree. Vector, SQL, BM25, graph, English.

Every query — SQL, vector topk, BM25 full-text, graph traversal, or natural language — compiles to the same JSON-serialisable Plan AST. The same volcano-style executor walks rows, indexes, postings, and chunks; predicate rewriting folds constants and pushes filters under joins before the cost model ranks shapes. Numeric filters run through SIMD kernels (AVX2 on Intel, NEON on ARM, portable std::simd elsewhere), and chained joins build a left-deep tree up to five tables.

A natural-language question lands in the same Plan tree as a hand-written SQL statement, so an LLM-generated query gets the same cost model, the same EXPLAIN output, and the same per-node statistics as anything you write yourself. There is no LLM in the hot path: the model emits a plan, the executor runs it.

One row in. Every derived structure, atomically.

A single put_row writes the row, every secondary index, every forward and reverse edge, the per-row OCC chunk for declared extractions, the BM25 postings, and the vector embedding — all in one Store::write_batch. The whole batch lands as one WAL frame, hits one fsync, and broadcasts to the follower as one unit.

Your derived structures never drift from your rows. A torn frame drops the entire batch on recovery, so there is no half-written state where the row exists but its index does not. Edges are diffed before write, so reassigning a foreign key never leaks a stale reverse edge.

Active-passive replication. RPO = 0. ~25 s RTO.

Every committed WAL frame ships to a passive follower in real time. async, sync_one, and sync_quorum are per-write opt-ins, so you tune latency and durability per call. On paid tiers, sync replication delivers RPO = 0 — no acknowledged write is ever lost on writer failure.

An S3-backed lease is the strongly-consistent arbiter of which node is primary. When the writer dies, the lease expires, the follower takes the lease, and is promoted within ~25 seconds. New replicas bootstrap via a Frame::Snapshot transfer rather than replaying the entire log, so adding capacity does not stall your writer.

Point-in-time recovery. Restore to a moment.

WAL frame v2 embeds a timestamp_micros field at write time, so every byte that lands in the log knows when it happened. Sealed segments ship to S3 continuously, and a tail-shipper streams the open segment between seals — your archive is never more than a few seconds behind production.

Restore-to-timestamp at sealed-segment granularity is a one-click action in the dashboard or a single HTTP call. The platform reconstructs the database into a fresh instance at the requested moment, replaying frames up to the chosen segment boundary. Roll back a bad migration, recover a corrupted tenant, or branch a forensic copy — without touching the live writer.

Every query. Every span. Your stack.

Every query carries a query-id returned in X-OC-Query-Id. Append ?explain=true to any endpoint and the response includes the plan tree annotated with estimated rows, actual rows, time, chunks read, and segments pruned by the stats sidecar — no separate EXPLAIN endpoint, no separate auth path. Cancel an in-flight query by id and the response closes cleanly. Spans push to your OTLP collector with tail-based sampling, so every slow query gets traced automatically while fast queries stay cheap.