Tenants

A tenant is Eelden's consistency and isolation boundary. Every query runs against the current tenant. Transactions never cross tenants. Forks and snapshots are O(1) copy-on-write catalog operations over versioned pages.

Why this is not an app-layer tenant_id project: Shift left · Business value.

Catalog operations

In language (parsed; also available via Studio / HTTP /ops):

create tenant "acme"
fork tenant "acme" as "acme-staging"
snapshot tenant "acme" as "pre-launch"
suspend tenant "acme"
delete tenant "acme"

Op	Effect
create	New empty tenant in the catalog
fork	Copy-on-write child sharing page identities until writes diverge
snapshot	Named point-in-time pin used by asof and Studio time-travel
suspend	Mark tenant unavailable for normal use
delete	Remove catalog entry (reclaim is queued; protected tenants refuse delete)
compact	Rewrite live rows for a tenant (eelden compact / /ops)

Default tenant

Opening a database binds default. Studio routes as /#/t/:tenant. HTTP paths are /api/v1/t/:tenant/….

What isolation means today

• Queries and atomic blocks see one tenant's collections only.
• CDC tails are per-tenant.
• Schema fingerprints and lazy migration apply per tenant on touch.
• across tenants(pred) collection parses but does not execute yet — see Status.

Cross-tenant work

App-layer pattern: emit CDC from each tenant, maintain a read model, coordinate with sagas. The engine will not offer cross-tenant ACID.