Databases.

The database surface is a protocol layer, not a database. tenzro-database models a database as a DatabaseDescriptor — an engine id, a placement, a partition/replica count, an opaque per-engine config, an access policy, and an optional confidential seal. It computes placement and gates access; it never links a tensor library or an engine driver. The node layer holds the EngineRegistry that maps an engine id to a driver and dispatches queries to it.

One dial moves a database along a local → global continuum. A developer starts on their own machine and rescales outward in place, without recreating it or moving the connection.

• local — this machine only; one in-process or single-container partition.
• lan_cluster — a discovered local segment (mDNS + reachability); partitions and replicas placed across reachable local members.
• network — holders across the network; the descriptor is gossiped on tenzro/databases so peers converge on the same shape.

Local and LAN databases have no network holders to announce and are not gossiped.

For engines that ship their own cluster fabric — Postgres/Citus, Valkey Cluster (and the cataloged Milvus, Dgraph) — Tenzro places the engine's own roles (coordinator, worker, query node, primary, replica) rather than sharding rows itself. For an engine that is single-node in a segment — Qdrant in the local/LAN tier — Tenzro orchestrates the sharding by placing one standalone instance per partition. Each engine declares which model it uses so placement never fights the engine's design.

tenzro_listDatabaseEngines returns the catalog. Every entry carries its data models, pinned version, container image, license, and cluster model. Engines under a source-available license that restricts hosting are excluded. Five engines ship a driver; a create or query against an engine no node serves returns a routing error.

• PostgreSQL (driver) — relational, vector (pgvector), graph (Apache AGE). Engine-native sharding via Citus.
• Qdrant (driver) — vector. Tenzro-orchestrated, one standalone instance per partition.
• Valkey (driver) — key-value. Engine-native (Cluster: primaries + replicas).
• Lance (driver, embedded) — vector. Single-node, in-process.
• Tantivy (driver, embedded) — full-text. Single-node, in-process.
• Milvus (catalog-only) — vector. Cataloged so a descriptor can target it; no node driver is linked yet.
• Dgraph (catalog-only) — graph. Cataloged so a descriptor can target it; no node driver is linked yet.

A node does not run an engine as a subprocess. The operator runs PostgreSQL, Qdrant, or Valkey wherever they like and points the node at it; the driver is a thin stateless client. Embedded engines are the exception — Lance and Tantivy serve in-process under the node's data directory, no external process. The operator owns the engine's lifecycle, backups, and upgrades; the node owns placement, access adjudication, and query dispatch.

• postgres_url — connection string for the operator's PostgreSQL.
• qdrant_url + qdrant_api_key — the operator's Qdrant endpoint.
• valkey_url — the operator's Valkey endpoint.
• lance_embedded / tantivy_embedded — serve the embedded index in-process.

engine_config is an opaque per-engine JSON object, so a developer drives the engine's full native configuration rather than a lowest-common-denominator subset. The node validates it against the engine before placement — an unknown key or a value the engine cannot honor fails the create; it is not silently dropped. What lives there is engine-specific: Citus shard count and colocation for Postgres, collection and index parameters for a vector engine, cluster slot and replica policy for Valkey.

Every database is owned; an unowned database cannot be created. Access control is shared with file storage — the same AccessPolicy gates a database and a stored object identically.

• public — any caller may read; only the owner administers.
• owner_only — only the owner DID may read or administer. The default when a create supplies just owner_did.
• did_allowlist — a named set of reader DIDs may read; the owner administers.
• capability_required — reads and writes require an AAP capability naming the read/write action; the owner always administers.

The node adjudicates every query and every admin op fail-closed before any engine work runs.

A network-tier database holding sensitive data can carry a ConfidentialSeal — encryption-at-rest with one wrapped data key per authorized DID (hpke-x25519-hkdf-sha256-aes-256-gcm). The crate records the wrapped-key envelopes; the node and client do the crypto. This is opt-in on top of the always-on access policy: a capability gate for every tier, encryption-at-rest for sensitive network data.

A developer uses a Tenzro database the way they use a hosted one — a credential scoped to that database, and queries dialed with it.

tenzro_issueDatabaseConnection mints the credential. The caller must be the owner (or hold the write-action capability). It returns an AAP capability token pinned to that single database (allowed_resources: [database_id]), a mode of read_only or read_write, a TTL, and the query method to call.

tenzro_databaseQuery {
  database_id, caller_did, body,
  partition_index?, write?, capability?
}

body is the engine's own query payload — SQL for Postgres, a vector search for Qdrant or Lance, a full-text search for Tantivy, a command for Valkey. If this node holds the target partition it dispatches to the engine driver and returns the result; if not, it returns the holder endpoints so the caller reaches one that does. There is no silent local execution against a partition this node does not hold.

tenzro_rescaleDatabase grows or shrinks a database along the continuum in place. It is administrative — the caller passes the owner DID or a write-action capability. It recomputes placement over the current cluster candidates and rewrites the partition rows; a network-tier result is re-gossiped so peers converge on the new shape. A database created local with one partition can move to lan_cluster and then network with more partitions and replicas as demand grows.

Databases mirror the two-sided model of the rest of the network. A developer can run engines on their own machine or LAN cluster and serve data from there, or place a database across network holders and query it over the network — the same descriptor, the same connection credential, the same query method for both. One node's stake and one set of obligations back everything it holds across compute, file storage, and databases at once.

tenzro database engines
tenzro database create --id <id> --engine <engine> \
  --placement <local|lan_cluster|network> \
  --partitions <n> --replicas <n> --owner-did <did> [--config <json>]
tenzro database connect --id <id> --caller-did <did> [--write] [--ttl <secs>]
tenzro database query --id <id> --caller-did <did> --body <json> [--write]
tenzro database rescale --id <id> --caller-did <did> --placement <mode>
tenzro database drop --id <id> --caller-did <did>