One query language
QQL covers tables, filters, joins, writes, full-text search, graph traversal, vector similarity, and response shaping. One planner, one envelope, one authorization gate.
Qirava DMSqdms
One execute primitive, one function registry.
A zero-dependency data/app runtime you can install directly. Governance, database, workers, jobs, replication, and planned KMS stay behind one function registry, reachable only through execute(), only via a worker. Use it embedded, standalone, or as today's single-leader cluster. Apache-2.0.
execute primitive1
auth checkpoints3
one port: HTTP·WS·SSR7179
third-party deps0
What it is
Governance + DB + workers in one runtime
Qirava DMS is a single data system shaped for AI workloads. You write one query language and get tables, full-text search, graph relationships, and vector similarity from the same runtime — durable through a write-ahead log, and gated by one access model. No second database, no sidecar, no third-party dependency.
Durable by default
Every mutation lands in a write-ahead log before it's acknowledged, so a crash replays cleanly. Durability is built into the engine, not bolted on.
Workers host APIs and apps
Routes, pages, assets, jobs, users, and grants are data. Workers run before → handle → after pipelines, so APIs and Quill apps are hosted by the same governed runtime.
Features
The stack pieces stay inside one governed binary
Each capability is a function in the same registry behind the same executor. New capability means a new function — never a new entry point or a new service to run.
Multi-model queries
Join relational data, run search, walk a graph, and rank by vector similarity in one place. One language, one planner, one engine.
Transactions you can trust
ACID semantics on top of a write-ahead log: commits are atomic and durable, and recovery is a replay — no separate journal service to babysit.
Governance built in
Sessions or HMAC-signed API keys identify the caller; role-based grants (custodian > admin > user > guest) decide what they can touch. No add-on auth layer.
Self-describing API
/api/spec returns the live function catalog as JSON, and /api/spec/openapi returns OpenAPI 3.1 — generated from the registry, so the spec can never drift from what runs.
Admin app included
Qirava Studio is the default admin UI — a Quill app that runs as just another DMS client, through the same execute() path and the same auth checkpoints. No privileged backchannel.
Install direct, scale later
Single-leader replication keeps a follower in step with the leader's WAL, so a standby has the data. Dual-master clustering is the next step.
How it works
A request's life: before → handle → after
Every request flows through the same pipeline and crosses the same three gates in the same order. Reading the list below is reading exactly what happens on a call.
The worker pipeline
A worker runs before-functions (authenticate, set up context), then the handler, then after-functions. Auth is simply the first before-function — it writes the caller's identity into shared context for everything downstream.
Three checkpoints, one door
L1 the worker authenticates the caller. L2 execute() checks the target function's scope (public, all-apps, system, or owner). L3 the planner — the only door to the tables — enforces app-scope ∩ principal-grant. Nothing reaches the data around it.
Config lives in the database
Routes, pages, assets, users, and grants are rows in _sys_* catalog tables, so changing how the system behaves is just changing data — versioned, queryable, and served by the same engine that serves your app.
Architecture
From request to data — one allowed path
A request passes the worker, the executor, and the planner before it ever reaches the tables; the diagram lights each stage in turn. The same engine is assembled from the q* module family: qpkgs (stdlib), qquill (UI), qdms (the data system), and qcloud (managed control plane).
WorkerL1 · authenticate
execute()L2 · function scope
PlannerL3 · the only db door
Enginetables · WAL · indexes
AppsStudio · Quill · Cloud clients
Status
What's built, and what's next
The engine, the worker/serving layer, the access model, and AI retrieval are shipping. Clustering and a couple of subsystems are honestly still in flight.
- Execute primitive + function registryOne bounded executor, one registry; every subsystem reachable only through execute().Built
- Worker layer on one portbefore → handle → after serving HTTP, WS, and native SSR/SSG/ISR from a single listener.Built
- L1/L2/L3 access modelL1 before-auth, L2 execute scope, L3 planner RBAC. Sessions re-read live role; API-key grants intersect with table access.Built
- Self-describing API + Studio/api/spec (JSON) and /api/spec/openapi (OpenAPI 3.1) from the live catalog; Studio admin app runs as a DMS client.Built
- Search, graph, vector, WAL, jobsThese are built into the DMS path rather than delegated to separate services.Built
- KMS + compliance modeWORM/retention/access controls exist and encryption policy is marked; KMS-derived encryption, worker secret/env reads, and the packaged compliance mode are planned.Partial
- Managed Cloud orchestrationCloud will run DMS as thread/RAM/storage capacity with no-disruption vertical/horizontal scaling; real infra effects are not shipped yet.Planned
Build on the DMS
Start with the getting-started guide, browse the self-describing API reference, or read the three-checkpoint access model end to end.