- Create decisions/ directory with 32 numbered ADRs (ADR-001 through ADR-032) extracted from inline DD/SD/ED/SE decision sections - Create open-questions.md with 16 OQs organized by theme, cross-referenced to ADRs, with status tracking (resolved/open) - Create README.md as architecture index with doc table, ADR table, and lifecycle status definitions (draft/reviewed/stable/deprecated) - Replace inline decision sections in all spec docs with ADR reference tables - Replace inline open questions with OQ references to centralized tracker - Update frontmatter: metagraph-module.md, overview.md, sqlite-host.md → reviewed; schema-evolution.md and encrypted-data.md remain draft - DD1-DD10 → ADR-009 through ADR-018 - D1-D8 → ADR-001 through ADR-008 - SD1-SD5 → ADR-019 through ADR-023 (SD5 folded into ADR-006/008) - ED1-ED5 → ADR-023 through ADR-027 - SE1-SE5 → ADR-028 through ADR-032
981 B
981 B
ADR-019: JSON text for schema columns in SQLite
Status
Accepted
Context
SQLite stores JSON as text with { mode: "json" }. PostgreSQL uses native jsonb. The choice affects queryability and validation behavior.
Decision
SQLite uses text with JSON mode for schema, config, attributes, metadata, and allowedSourceTypes/allowedTargetTypes columns. JSON validation relies on application-level TypeBox schemas, not database constraints. SQLite is for spokes (local, infrequent queries); PostgreSQL is for the hub (frequent, complex queries where jsonb queryability matters).
Consequences
- SQLite cannot efficiently query inside JSON columns (no GIN indexes)
- All JSON validation is application-level (
Value.Check) - PostgreSQL gets queryability benefits from
jsonbwhen implemented - The dual-host strategy is appropriate: SQLite for local infrequent access, PG for hub-level querying