Our depth-first roadmap to 1.0

OriginChainDB Team · May 5, 2026

roadmap product design architecture

TL;DR - OriginChainDB’s roadmap to 1.0 is depth-first by deliberate choice. Six months of HA → fuzzing → optimiser → EXPLAIN → multi-writer → online-schema, and zero new “shapes” of data (no graph, no full-text, no time-series specialty types) in that window. No step starts until the previous one has run in production for at least one paying customer.

The breadth temptation

When you’re building an AI-native database, the easy roadmap writes itself. Customers ask:

“Can you add a graph engine for relationship queries?”
“Can you add full-text search so we don’t need OpenSearch?”
“Can you add time-series compression for telemetry workloads?”
“Can you add geospatial indexes?”

Every one of those asks is reasonable. Every one of them is also worth a year of engineering.

If you say yes to all of them, you ship a database that does eight things mediocrely. The vector substrate handles small loads but falls over at scale. The graph engine works on toy datasets but doesn’t have a real query optimiser. The full-text search is a port of an old library and has half the recall of a dedicated FTS engine. Customers who pick you because of the “it does everything” pitch end up dropping you because of the “but none of it works in production” reality.

We’ve watched that movie before. We’re not making it again.

What depth-first means here

Depth-first means: every quarter, we ship one capability that fully works at scale, with the boring parts (HA, observability, recovery, performance under load) done before we declare it shippable. We don’t move on until that’s true.

Concretely, the locked plan to 1.0:

HA + automatic failover - done. Snapshot bootstrap landed; chaos drill passes. To be precise about what that buys: a write is acknowledged only once it is flushed to durable storage on the instance, and a standby can be promoted to take writes, with automatic promotion available as an opt-in that refuses a standby which is not fully caught up. Replication to that standby is asynchronous, so an abrupt loss of the primary can still cost the most recent writes - the seeding gap is closed, not the replication gap. (Read the post.)
Crash-testing the substrate - in progress. Crash-test the substrate at every durability boundary; build automation that finds invariant violations under fault injection. (Read the post.)
Cost-based optimiser - next. Replace the current rule-based plan with one that estimates I/O cost across shapes and picks the cheapest path.
EXPLAIN - alongside (3). Show developers what the planner actually did so debugging slow queries is a 30-second loop, not a four-hour mystery.
Multi-writer - after (4). Allow more than one concurrent writer without breaking the per-key consistency story. This is a hard problem; we want the rest of the substrate proven before we touch it.
Online schema evolution - last. Shape upgrades that don’t require any read or write pause, with the dual-read transform automated end-to-end.

Each step is one full quarter of engineering. Some are longer. None overlap; we don’t start step N+1 until step N is in production for at least one paying customer.

What we’re explicitly not doing in this window

Feature	Status	Why not yet
Vector search at >100M	Works at <10M today	Optimiser work in step 3 unblocks larger ANN
Graph traversal	Not on roadmap	Adjacency-list shapes can model it; no native engine before 1.0
Full-text search	Not on roadmap	Indexed string equality covers most AI use cases; FTS post-1.0
Time-series compression	Not on roadmap	Standard shapes work; columnar compression later
Geospatial indexes	Not on roadmap	Niche enough we wait for a paying customer to ask
SQL surface	Not on roadmap	We have a typed query API; SQL adds a parsing layer with no functional benefit
Self-hosted distribution	Not on roadmap	Managed-cloud only - full stop

These will come, eventually, in some order. Probably not in the next six months. We’d rather you can rely on the things we do ship than have a long list of things that kind of work.

Why this is the right bet for AI-native

Three reasons.

1. AI workloads punish weak engines harder than transactional workloads do. A traditional CRUD app touches a few rows per request. An AI agent loops, hammering hundreds of writes and reads per session, often with retries and tool-call branches. A database that’s “fine for most workloads” turns into a bottleneck on hour two of an agent run. The substrate has to be tight before the layer above it matters.

2. The features customers actually need first are infrastructure, not data shapes. Talk to teams running AI features in production. Their top complaints are: “the latency variance ruined our agent loop,” “the failover lost data and we found out from a customer,” “we can’t tell why this query is slow,” “schema migration broke the eval pipeline.” These are all infrastructure problems, not data-shape problems. Depth-first addresses them; breadth-first doesn’t.

3. AI-native means less ceremony, not more shapes. Adding a graph engine doesn’t reduce the developer’s mental load - it adds a new query language to learn, a new failure mode to debug, a new index to size. Key shapes already model graphs (adjacency-list shape + index on the “to” side) without inventing new vocabulary. The right answer for “AI-native” is fewer specialty engines, not more.

When does this stop?

When 1.0 ships, the substrate is verified at production scale, the planner is honest about cost, multi-writer is online, and schema evolution is invisible. Then we start saying yes to the breadth requests - and even then, only for the ones a paying customer is asking for.

The roadmap after 1.0 isn’t pre-decided. It’ll be customer-driven, and we’d rather have a small list of customers asking for the same thing than a long list of features no one is paying for.

What this means for you, today

If you’re evaluating OriginChainDB right now, the honest answer is:

Use us if your workload is JSON records + vectors + light secondary indexes, and you care more about p99 latency, atomic multi-shape writes, and durable-on-commit writes with automatic failover than about feature breadth.
Wait if you need full-text search, geospatial, graph traversal, or columnar analytics. None of those land before 1.0.
Talk to us if you’re somewhere in between. Sometimes a workload that seems to need a specialty engine actually models cleanly as shapes.

The depth-first decision is a commitment to the customers we have, not the features we could ship. We’d rather lose a deal because we don’t have feature X than win it and miss the SLA we promised.

FAQ

Why isn’t vector search higher on the priority list?

Vector search at small-to-medium scale works today. The ANN performance we have is good enough for sub-10M-vector corpuses. The optimiser work in step 3 of the roadmap is what unblocks much-larger ANN; until then, the bottleneck is plan selection, not the index.

When will graph queries / full-text / time-series land?

Post-1.0, customer-driven. We won’t pre-commit to a quarter for any of them - that’s the point of depth-first. If you need one of these now, we’re not the right database.

What does 1.0 mean concretely?

A version of the substrate where every step in the depth-first roadmap is shipped, the cost-based optimiser is verified against real workloads, multi-writer is GA, and online schema evolution requires zero application changes. The number on the version isn’t the point - those properties are.

Are you taking enterprise customers in this window?

Yes, but with eyes open. We’re transparent about what works (depth-first capabilities above) and what doesn’t yet (breadth). Enterprise customers in this window are the ones aligned on “we want the substrate done well first.”

Will the roadmap change?

The order might shift if a step takes longer than expected. The depth-first principle won’t. Adding a new top-level capability before 1.0 is the change we won’t make.