Skip to main content

Nine logical databases and boundaries

A cell does not keep its state in one database. It partitions state into nine logical databases, each with a distinct domain, its own manager instance, its own connection pool and write lock, and its own replication adapter. Eight are SQLite (transactional); the ninth, metrics, is a DuckDB analytical store.

The boundaries between them are architecturally enforced: directory objects never appear in the system database and vice versa, and cross-database queries do not exist. A service that needs another domain's data calls the owning service or reads its local replica, it never reaches across into another domain's store. That constraint is why the estate is auditable at all.

The nine databases​

Figure C1: the nine logical databases of one cell. Cylinders are the eight SQLite (transactional) domains; the hexagon is the ninth, the DuckDB (analytical) metrics store. The teaching is the absence of arrows between the boxes: there is no DB-to-DB edge because no cross-database query exists. A domain reaches another only by calling the owning service or reading that domain's local replica (lower box). Metering is not a database, its tables live inside the system domain; the DuckDB metrics store is a separate analytical database. This holds identically single-cell and multi-cell.

Table equivalent

#DatabaseEngineKindDomain it owns
1systemSQLitetransactionalCells, service groups, fabric leases, runtime state, system crypto: and metering tables
2directorySQLitetransactionalOrganizations, nodes, users, entity profiles, entity crypto
3sessionsSQLitetransactionalSession state
4messagesSQLitetransactionalMessaging and streaming state
5catalogSQLitetransactionalThe catalog of assets, lineage, contracts
6storageSQLitetransactionalObject-storage metadata
7computeSQLitetransactionalCompute and job state
8dataSQLitetransactionalUser-facing multi-model data
9metricsDuckDBanalyticalMetrics and analytical roll-ups (not metering)
RelationshipPresent in the figure?Why
DB → DB (cross-database query)No: deliberately absentCross-database queries do not exist; the absence is the boundary
Service → owning serviceYesA domain reaches another domain's data by asking its owner
Service → local replicaYesOr by reading a locally replicated copy of that domain

Why the boundary is enforced, not conventional​

If a boundary were only a naming convention, any caller who reached a store another way could ignore it. Instead each database is a separate manager with its own pool and write lock, and there is no query surface that spans two of them, so "which data lives in which domain" is a structural fact, not a guideline.

This is the same principle the governed read applies to row filters and column masks, and the same one workspaces and clean rooms apply to ownership: the control is part of execution, so it cannot be bypassed by choosing a different door.

Schema, replication, and scope decided together​

When a new table is added, its DDL, its replication policy, and its workspace-scope classification are declared in the same place, at the same moment. So "which data crosses which boundary" is a property of the schema itself, not of a downstream configuration file someone forgot to update.

Across the deployment matrix​

  • Single-cell: nine databases, nine managers, one process tree; the boundaries are local.
  • Multi-cell: each database carries its own replication adapter, so a domain replicates on its own terms; the no-cross-database-query rule holds per cell.
  • Sovereign / air-gapped and cloud-enabled: the partitioning is a property of the local engine, so it holds identically with or without connectivity.