storage-is-fully-production-grade-across-backends
IN derived (depth 4)
Both storage backends achieve fully production-grade operation — concurrent access optimization (WAL mode, derived FTS5 indexes), equivalent safety guarantees (atomic isolated mutations through backend-appropriate mechanisms), and multi-tenant isolation — when both backends provide complete API coverage.
Summary
The storage system is ready for real production use regardless of which database backend you choose. Both SQLite and Postgres handle concurrent readers without blocking, support full-text search, keep mutations atomic and isolated, and can safely run hypothetical reasoning without corrupting data — so the backend choice comes down to operational preference, not capability gaps.
Justifications
SL — Concurrent-access optimization and backend-agnostic safety together yield production-grade storage, gated on PgApi reaching full API parity with the SQLite backend.
Antecedents (all must be IN):
- storage-optimizes-concurrent-access-and-search — The storage layer optimizes for both concurrent access (WAL mode enables non-blocking reads during writes) and full-text search (derived FTS5 index rebuilt from scratch on every save guarantees consistency), making the persistence layer production-ready for multi-reader workloads with search capability.
- storage-layer-is-backend-agnostic-and-safe — Both storage backends provide equivalent safety guarantees through backend-appropriate mechanisms: atomic isolated mutations (context-managed load/save for SQLite, per-method transactions for PgApi) and safe hypothetical reasoning (write-flag gating for SQLite, transaction rollback for PgApi), making safety properties independent of backend choice.
Unless (any of these IN defeats this justification):
- pgapi-partial-api-coverage — PgApi implements core operations (add/retract/assert/search/nogood/explain) but defers simulation, dialectics, namespace support, import/export, and maintenance operations to future work