Datastores
What the product stores, what it brings with it, and the stores you supply.
⚠ First pass. This page says what the stores are FOR and who owns them. It does not yet carry sizing, retention, backup procedure or tuning.
The record: an embedded file, or PostgreSQL
Out of the box the product keeps its record in one embedded file (SQLite) — gate decisions, run records, costs, refusals, observed git facts. Nothing to install and nothing to operate.
PostgreSQL is the other backend for the record — the same content, under a database you
already know how to operate: your backups, your replication, your retention, your monitoring.
It is chosen in configuration with store.backend = postgres, and the connection string is read
from the environment variable that store.postgres_dsn_env names — the configuration never
holds the connection string itself. We supply the binaries, you supply the database: an
enterprise already has a PostgreSQL practice, and a product that shipped its own would be asking
you to operate a second one.
⚠ Choose the backend before the record grows. This site has no procedure for moving an existing embedded record into PostgreSQL.
What you supply from the first install: CouchDB
CouchDB holds the document classes the product treats as signed rules and evidence — law, working material, and optionally a record and a telemetry database — the classes that are replicated and delivered rather than queried. It is a different job from the record above, which is why it is a different store rather than more tables.
The setup page asks for a CouchDB node and does not continue until it answers; it can start one on the same machine for you. Saphan Studio then creates its databases on it, each with its access rule — CouchDB: the databases Saphan Studio creates says which, and which of them are the only copy of what they hold.
What is not written yet, stated plainly
- Sizing and growth — how much either store needs for a fleet of a given size.
- Backup and restore — the procedure, and how a restore is verified rather than assumed.
- What happens when a store is unreachable or refuses — the refusal a reader will actually meet, and what to do about it. ⚠ This is the gap that matters most operationally, and it is named here rather than left for a bad afternoon.
- Moving the record from the embedded file to PostgreSQL.
⇒ Until those land, plan the installation with the embedded record and treat PostgreSQL as a decision you make deliberately, with us, rather than one the documentation can yet talk you through alone.