Inside a cell
A cell is a complete instance of the platform, which means it carries its own stores rather than reaching for someone else's. This section describes what those stores are and how they are walled apart.
Nothing on these pages is something you create, size, back up, or query. The databases below are the cell's own internal state, and the cell manages their schema, replication, compaction, and retention for itself.
For the stores you do provision and use, catalogs, tables, structures, storage namespaces, streams, and data products, see the Data Platform.
In this section
| Page | What it covers |
|---|---|
| The database substrate | The per-cell transactional store, object store, and multi-model engines, and why locality is what makes sovereign operation possible |
| Logical databases | The nine internal databases a cell partitions its state into, and why cross-database queries do not exist |
Why it is worth reading anyway
You will never administer these databases, but two properties of them explain platform behavior you will see.
Locality is why disconnected operation works. A sovereign or air-gapped deployment cannot reach a cloud service to answer a query, check a policy, or record an audit event. Because the substrate is local to the cell, nothing in those paths reaches for a network.
The boundaries are why the estate is auditable. Domains cannot query across each other, so "which data lives where" is a structural fact rather than a convention a caller can ignore. That is the same principle the governed read applies to rows and columns, applied one level down.
Related
- The cell model, what a cell is and how cells compose.
- Platform services, the nine service processes that run on a cell.
- Replication, DR & federation, how state crosses between cells.