DATABASEOne transaction.
From intent to storage.
Qirava puts database correctness in one engine. The host changes how you connect. It does not create a second set of commit rules.
A common engine,
wherever it runs.
The public Rust library and standalone server call the same coordinator. QQL, typed record operations, schema validation, unique constraints and object references converge before commitment.
The planner chooses candidate access. A shared execution context keeps resolved records available through the transaction.
Follow the actual request path.
The planner selects complete candidate access paths using primary keys, declared secondary indexes and supported scalar ranges. Selected fields and repeated record addresses remain available to the transaction’s shared execution context. Joins reuse indexed probes by distinct key, or build one keyed map.
READ Snapshot execution
- Capture snapshot
Pin one complete committed database view.
- Check receipt
Reject a reused request ID with different operations.
- Plan candidates
Primary key, declared index, range, union or scan.
- Execute in context
Reuse resolved records and selected fields; apply residual predicates.
- Return snapshot result
Validate result size. No WAL write for an ordinary read.
Readers do not hold the writer coordinator while evaluating queries.
WRITE Durable commitment
- Admit & prepare
Build a private candidate outside the commit coordinator.
- Finalize in the planner
A held commit fence keeps receipt and dependency checks valid through publication.
- Reuse, merge or re-execute
A changed dependency can require another execution.
- Stage record & index deltas
Schema, revision, uniqueness, object links and TTL use one authority.
- Flush private trees
Bounded foreground buffers coalesce changes before staging roots.
- Prepare resolved WAL
Retain resolved changes and the original receipt; V2 page roots describe the prepared view.
- Persist the commit
Sync private pages, WAL group, commit journal and durable head.
- Publish & acknowledge
Readers see the whole committed snapshot; retries resolve its receipt.
Unordered aggregates now consume each input once and share field resolution across aggregate functions. Sorts resolve keys once and select the requested result window before sorting its row positions. Neither change removes residual checks or changes transaction commitment.
Residual predicates still validate candidates. The request context has a 32 MiB retention budget; it is not an unlimited global cache. Concurrent writes may invalidate a prepared candidate and require re-execution. Indexed candidates currently materialize key vectors. Index-driven ordering, repeated scan reuse, blocking I/O and coordinator restaging remain active performance work.
Foreground tree buffering is under validation: up to 128 keys or 256 KiB per private tree, sharing a 64 MiB retained-write budget. It reduces repeated page-path writes within a transaction while preserving individual commit receipts. Complete global operator and I/O admission remains open.
Acknowledge the durable boundary.
The planner validates schemas, revisions, uniqueness and object links, retaining the selected reads and original result. WAL storage accepts resolved transaction bytes and assigns sequences from its recovered memory state. Physical pages and authenticated commitment are still synchronized before atomic publication of the complete state and receipt.
V2 physical WAL recovery restores a durable checkpoint and replays resolved changes and original receipts above it. Prepared tail pages may be lost; missing or damaged checkpoint data still requires recovery from a valid copy. A checkpoint-only open retains the fast root restore. Replaying an uncheckpointed tail currently increases reopen time and private-page growth. Durable asynchronous application remains in development: committed record and index overlays, resumable jobs and applied checkpoints must be verified before page synchronization can leave the response path.
The planned request lifecycle persists authenticated intake before QQL or typed planning, including reads. Default mutation responses follow WAL commit and coherent visibility; an optional wait also covers durable execution. Restart resumes pending work from recorded cursors. Cleanup retains terminal results and retry protection before deleting intake. These lifecycle options are not available yet.
Storage has a lifecycle.
| Layer | Responsibility |
|---|---|
| Authenticated page trees | Ordered records and auxiliary indexes; immutable roots identify a committed view. |
| Shared page and decoded-node cache | Validated decoded nodes reuse keys and values under the same byte and entry budget as payload pages. Reader pins remain charged; parent/child checks still run on cache hits. |
| WAL and durable head | Authenticated recovery of committed transactions and receipts. |
| Checkpoints and generations | Preserve consistent state, replay its tail and reclaim replaced storage through verified ownership. |
| Immutable object parts | Authenticated, bounded-window reads; transactional manifest and record-reference publication. |
| Native / external authority | Release the configured instance key through recovery; fail closed when unavailable. |
Encryption at rest is optional and defaults off for new databases. Integrity checks, custody and durable publication apply in both modes. Existing protection modes are preserved.
Page primitives and verified generations are implemented. Public storage-policy selection, total resource admission, retention, large cold datasets and physical power-loss acceptance remain open.
Cluster means shared authority.
The target starts with three logical shards in every mode, colocated for embedded or standalone deployment. The target fixes local replication at two complete copies. Cluster requires at least three nodes, defaults to two copies on distinct nodes, and alone permits increasing that count. Two copies on one host do not provide host-failure tolerance. Shard count, data copies and consensus voters have separate roles; safe ownership and quorum decisions are still required.
Standalone ↔ cluster movement must preserve revisions, receipts, indexes, objects and authorization under live traffic and crashes. Targets must verify the required copies before fenced activation diverts new traffic. Mixed-version upgrades require compatible read/write/apply adapters and a durable version barrier while traffic continues. These requirements are not implemented by copying encrypted files asynchronously.
Planned read-only followers resume authenticated WebSocket WAL streams from verified checkpoints, apply resolved changes through the same engine and expose their applied position. They need gap detection, backpressure and fenced promotion; a live connection alone cannot guarantee current leader reads.
Read the current capability boundary →