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.
Catalog operations
In language (parsed; also available via Studio / HTTP /ops):
eel
create tenant "acme"
fork tenant "acme" as "acme-staging"
snapshot tenant "acme" as "pre-launch"
suspend 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) |
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
atomicblocks see one tenant's collections only. - CDC tails are per-tenant.
- Schema fingerprints and lazy migration apply per tenant on touch.
across tenants(pred) collectionparses 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.