Operating modes

Choose where the engine runs without changing the meaning of a transaction.

On this page

Available development modes

Only one engine may own a database directory at a time. Share cloned handles within an embedded process, or connect to the standalone server for access from multiple processes. Network filesystems do not create replicas.

Mode	Boundary	Ownership
Embedded	qirava::Database in your Rust process	The host supplies a key or KeyProvider and owns the directory.
Local standalone	Unix socket or loopback HTTP	The server owns storage, sessions and configured recovery.
Remote standalone	Verified TLS 1.3 HTTPS	The server owns storage; clients receive API data, never the storage key.

Cluster and replica delivery

The required cluster design adds quorum commitment, leader fencing, complete snapshot and object transfer, membership changes, read consistency and shard ownership. A single asynchronous copy cannot satisfy these requirements.

Forward and reverse migration must preserve revisions, receipts, schema/index state, object hashes and authorization. Concurrent traffic and crashes must leave one writable owner. These are acceptance requirements, not available switches.

Studio, local and remote clients

Studio currently builds as static management assets served on the database origin. The portable TS client supports HTTPS and explicit loopback HTTP; an injected host transport can support Unix sockets. Browser access to local Unix sockets requires a desktop bridge or authenticated local daemon.

Studio supports multiple saved local/remote instances and exact-origin CORS, with per-instance credentials held in memory. Load-balancer failover, Tauri packaging and complete custody/role journeys remain under implementation. Do not treat a static build alone as verification of these paths.