Datastores
What the product stores, what it brings with it, and the two stores you supply when you outgrow the default.
⚠ 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 — those are being written, and where a number matters it will be a measured one rather than a guess.
What ships inside: a single-file store
Out of the box the product keeps its record in one embedded file — gate decisions, run records, costs, refusals, observed git facts. Nothing to install, nothing to operate, and it is enough to run a real fleet.
⇒ Start here. An installation that never outgrows it needs neither of the stores below.
What you supply: PostgreSQL
PostgreSQL is the store for the record at scale — the same content as the embedded file, under a database you already know how to operate: your backups, your replication, your retention, your monitoring.
Why yours and not ours (the owner's own ruling): we supply the binaries, you supply the database. An enterprise already has a Postgres practice, and a product that shipped its own would be asking you to operate a second one badly.
What you supply: CouchDB
CouchDB holds the document classes the product treats as evidence and as distributed state — signed documents, captured artifacts, the classes that must be replicated rather than queried. It is a different job from the record, which is why it is a different store rather than more tables.
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.
- Migration from the embedded file to PostgreSQL: the act exists; the runbook for it is owed.
⇒ Until those land, plan the installation with the embedded store and treat both external stores as a decision you make deliberately, with us, rather than one the documentation can yet talk you through alone.