38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
|
# ADR-0004 — Append-only evidence store, SQLite then Postgres
|
||
|
|
|
||
|
|
**Status:** accepted · **Date:** 2026-09-04
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
Blueprint §26 requires an evidence store favouring append-only history, with
|
||
|
|
mutable summaries derived from immutable events. §45 suggests a relational
|
||
|
|
starting model and explicitly argues it is simpler than a graph database for a
|
||
|
|
first implementation.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
One relational schema, two backends. SQLite for development, single-node
|
||
|
|
deployments and the CI conformance suite; PostgreSQL for anything shared. The
|
||
|
|
event table is append-only: no `UPDATE`, no `DELETE`, enforced by trigger rather
|
||
|
|
than by convention.
|
||
|
|
|
||
|
|
Summary tables are derived views, rebuildable from events at any time.
|
||
|
|
|
||
|
|
## Rationale
|
||
|
|
|
||
|
|
The first real workload — publishing hall-of-helix entries to a Telegram channel
|
||
|
|
— produces a handful of events per day. Requiring Postgres to run the framework
|
||
|
|
at that scale would be an operational tax with no return.
|
||
|
|
|
||
|
|
Keeping one schema across both means the CI suite exercises the same statements
|
||
|
|
production runs, which is where divergence usually hides.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
- Portable SQL only; no backend-specific features in the core path.
|
||
|
|
- Blueprint invariant 8 (every promotion is auditable) is a storage property,
|
||
|
|
not an application convention: rewriting history has to be blocked at the
|
||
|
|
database.
|
||
|
|
- Evidence-store failure must not stop the data plane (Blueprint §34.6). The
|
||
|
|
gateway serves from cached published configuration and buffers telemetry.
|