Skip to content

DMS roadmapqdms

The data system, honestly tracked.

What ships today, what is partial, and what is designed but not yet built. The engine, worker/serving layer, access model, search/graph/vector, WAL, jobs, Studio, and single-leader replication are shipping; KMS, worker secrets, compliance packaging, and cluster automation are planned. No dates promised — only state.

capabilities shipping13
partial3
planned5
third-party deps0

Status board

Built, in progress, and planned

Three lanes, no dates. Each item is sourced from the repository and the architecture docs — the BUILT lane is present and usable now; PARTIAL has a working seam with deferred parts; PLANNED is designed but not yet built.

Built

Shipping today

Present in the codebase and usable now.

  1. Engine: indexes, planner, streamingFilter/range/OR/AND/composite/join, sort-via-index, TTL sweep, and a plan cache — the planner is the only door to read or mutate.
  2. Vector (LSH), graph, and searchVector ANN via LSH, graph traversal, and search are in the engine — AI retrieval is a first-class query, not a second database.
  3. QQL + DDLThe query language plus CREATE TABLE / CREATE INDEX, recorded as data in _sys_tables / _sys_indexes.
  4. Worker pipeline: before → handle → afterEvery request flows through a before-chain and after-chain around the handler; auth is just the first before-function.
  5. One port: HTTP · WS · SSR/SSG/ISRFrom-scratch HTTP/1.1 (CORS, ETag, cache, TCP_NODELAY), WebSocket CDC fan-out, and native rendering on a single listener.
  6. Per-function schedulerA bounded executor governs every call; jobs run as registered functions with overlap control.
  7. Function registry + execute()One execute primitive dispatches one registry (static + dynamic); new capability is a new function, never a new entry point.
  8. RBAC L1/L2/L3 + governanceL1 before-auth, L2 execute scope, L3 the planner; custodian > admin > user > guest, deny-by-default, live authority re-read per request.
  9. Auth: sessions + HMAC keys + invitesSession and HMAC-signed-key surfaces; governance catalogs are write-denied on the QQL surface; custodian-gated single-use invites onboard as guest.
  10. Config-as-data (_sys_*)Routes, workers, functions, pages, assets, users, and grants are rows in _sys_* tables, with live hot-reload.
  11. Write-ahead log (WAL)WAL-before-apply for mutations; recovery replays only committed transactions and truncates a torn tail.
  12. Self-describing API + OpenAPIGET /api/spec returns the live function catalog as JSON; /api/spec/openapi returns OpenAPI 3.1, generated from the registry.
  13. Studio — the admin appQirava Studio runs as a DMS client over the same execute() path and the same auth checkpoints — no privileged backchannel.
Partial

In progress

A working seam exists; the rest is designed, not yet built.

  1. Single-leader replicationMaster → follower committed op-frames ship over a length-prefixed TCP transport; config-as-data and the WAL replicate through the same stream.
  2. Epoch fencingPer-record {shard_id, epoch, hlc} tags and a promotion-bumped term — needed for multi-node ordering and fencing — are designed, not yet wired.
  3. Write-forwarding + semi-sync acksFollower last_applied is tracked but not yet fed back into the master's commit gate; write-forwarding from a follower is pending.
  4. Authenticated replication linkThe replication socket assumes a trusted LAN today; reusing the HMAC-signed-key machinery to authenticate followers is the next hardening step.
Planned

Planned

Designed but not yet built — no dates promised.

  1. KMS backend + worker secret/env valuesMaster seed, KMS-derived DEKs, encryption-at-rest, and scoped worker secret reads. Frontend islands must never receive these values.
  2. Cluster automation + authenticated replicationHardening the current single-leader replication path with authenticated links, better catch-up/snapshot behavior, and operator-safe failover.
  3. M-of-N custodian seed ceremonyShamir-split master seed, multi-authenticator custodians (FIDO2 PRF + BIP39), engaged only at boot/governance — never per query.
  4. Confidential-compute attestationThe DMS boots inside a SEV-SNP / TDX VM and attests before receiving its seed; a startup security-tier banner states the residual risk.
  5. TS / WinterTC worker runtimeA TypeScript / WinterTC worker runtime alongside the native function model.
Builtshipping and usable today
Partiala working seam; the rest is designed
Planneddesigned but not yet built

Sourced from the architecture, the DMS docs, `docs/status.registry`, and source-backed security/governance notes.