Databases

Managed databases on network hardware: pick an engine and a placement, connect with a scoped credential, and pay per query. Every database is isolated per tenant.

A node with spare capacity can host databases for developers the way a managed database service does. You name an engine, choose how far the data should spread, and get back a connection credential scoped to that one database. Queries are metered, and a database can charge other callers per query.

Engines

Engine	Data models	Distribution
PostgreSQL	Relational, vector (pgvector), graph (Apache AGE)	Engine-native sharding
Qdrant	Vector	One instance per partition, placed by Tenzro
Valkey	Key-value	Engine-native cluster (primaries and replicas)
Lance	Vector	Embedded in the node
Tantivy	Full-text	Embedded in the node

tenzro_listDatabaseEngines (or GET /v1/databases/engines) returns the catalog, with each engine's data models, pinned version, licence and cluster model. Engines under licences that restrict hosting are excluded. A request for an engine no node serves returns a routing error rather than a silent substitute.

For engines that ship their own cluster fabric, Tenzro places the engine's own roles (coordinator, worker, primary, replica) rather than sharding rows itself. For engines that are single-node, Tenzro places one instance per partition.

Placement

One setting moves a database from your laptop to the network, in place, without recreating it or changing the connection.

Placement	Where partitions live
`local`	This machine only
`lan_cluster`	Machines discovered on your local network
`network`	Holders across the network

Start local, then tenzro database rescale to lan_cluster or network with more partitions and replicas as demand grows. Network-tier databases are announced to peers so every holder converges on the same shape. See LAN clustering.

Isolated per tenant

Every database is isolated at the engine, not only at the node. Each tenant's database runs under its own engine credentials, confined to its own namespace, so one tenant's queries cannot see or touch another tenant's data even on a shared engine.

Read-only grants are enforced. A read-only connection cannot write, whatever flags the caller sends: the node dispatches it with read-only engine credentials, and write statements are refused.

Access policies

Every database has an owner; an unowned database cannot be created. The same policies gate databases and stored files.

Policy	Who may read
`public`	Anyone; only the owner administers
`owner_only`	Only the owner DID. The default.
`did_allowlist`	A named set of DIDs
`capability_required`	Holders of a capability token for the read or write action

The node adjudicates every query and admin operation before any engine work runs, and fails closed. Owner and allowlist access require a signed DID envelope that binds the caller's DID, the method and a hash of the parameters, with a nonce to stop replays. Capability tokens are self-proving.

Confidential databases

A network-tier database holding sensitive data can carry a confidential seal: encryption at rest with one wrapped data key per authorised DID (HPKE with X25519 and AES-256-GCM). The seal is opt-in, on top of the access policy.

Connect and query

tenzro_issueDatabaseConnection mints a credential: a capability token pinned to one database, in read_only (the default) or read_write mode, with a time-to-live. Only the owner, or a holder of the write capability, can issue one.

bash

tenzro database create agents-kb --engine postgres --owner-did did:tenzro:human:... \
  --placement local --price-per-query 100000000000000 --asset TNZO

tenzro database connect agents-kb --caller-did did:tenzro:human:... \
  --bearer-did did:tenzro:machine:... --ttl-secs 86400

tenzro database query agents-kb --caller-did did:tenzro:machine:... \
  --body query.json --capability <token>

body is the engine's own query: SQL for PostgreSQL, a vector search for Qdrant or Lance, a full-text search for Tantivy, a command for Valkey. The node that holds the target partition runs it; any other node returns the holders' endpoints so the caller can reach one. There is no silent execution against a partition a node does not hold.

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

Over HTTP, the same operations live under /v1/databases with a database-scoped X-Tenzro-Api-Key: create and list at /v1/databases, and /query, /connections, /partitions, /usage and /rescale under /v1/databases/<id>.

Per-query pricing and metering

A database can set a price per query in a chosen asset. The owner always queries free. When anyone else queries a priced database, the serving node answers with JSON-RPC error -32402 and an x402 payment challenge for tenzro://db/<database_id>/query. The caller pays and retries with payment_credential; the node checks the resource, the amount and that the owner is the recipient, settles, and only then runs the query. Only the node serving the partition bills. See x402.

Every query is metered: query and write counts, bytes in and out, total billed and the last query time. tenzro_databaseUsage returns the counters and is limited to the owner or a write-capability holder.

Configure the engine

engine_config is the engine's own configuration as JSON, validated before placement: shard counts and colocation for PostgreSQL, collection and index parameters for vector engines, slot and replica policy for Valkey. Unknown keys fail the create rather than being dropped.

Host databases as an operator

Operators run PostgreSQL, Qdrant or Valkey themselves and point the node at them; Lance and Tantivy run embedded in the node. The operator owns the engine's lifecycle, backups and upgrades; the node owns placement, access checks, tenant isolation and query dispatch. Bond for the service with: