Data Isolation Model (PostgreSQL)
Audience: platform operators and module owners who need to understand how Stella Ops separates data between services and tenants. Scope: a high-level, descriptive map. For the authoritative table/column contracts, see Where to find authoritative schemas.
Stella Ops uses PostgreSQL as the canonical durable store. Isolation is achieved by three mechanisms:
- One schema per service — clear ownership boundaries; each service migrates and owns its own schema.
- Tenant identifiers on all tenant-scoped records — enabling row-level isolation strategies where required.
- Append-only patterns for evidence stores — preserving deterministic replayability of verdicts and audit trails.
Schema ownership map
| Schema | Owner (primary) | Data class |
|---|---|---|
authority | Authority | Identity, clients, keys, auth audit trails. |
scanner | Scanner | Scan manifests, triage, scan result metadata. |
vuln | Concelier | Advisory raw documents, linksets, observations. |
vex | Excititor | VEX raw statements and consensus state. |
scheduler | Scheduler | Job orchestration state. |
notify | Notify | Notifications state and delivery history. |
policy | Policy | Exceptions, policy snapshots, unknown tracking. |
orchestrator | Orchestrator | Workflow orchestration state. |
Where to find authoritative schemas
This document is descriptive. The authoritative contracts are:
- Module dossiers and migration notes under
docs/modules/<module>/. - Database schema reference: Data Schemas.
Related
- Infrastructure dependencies — the same schema-ownership map alongside the Valkey, object-store, and messaging dependencies.
- Security boundaries — trust zones and tenant-isolation enforcement.
- Schema mapping — PostgreSQL, Valkey, and RustFS storage reference.