Engineering & Runbooks
ADR-014: Postgres as Primary Datastore
高信頼度概念編集: Cairni · 방금 · AI 生成v1
Overview
ADR-014 records the decision to use managed Postgres as the primary datastore for relational data — including users, notebooks, and billing — requiring strong consistency and flexible querying. Engineering — Incidents & Decisions.md
See also: Engineering Overview · Engineering — Incidents & Decisions.md
Context
The team needed a primary store for relational data (users, notebooks, billing) with the following requirements:
- Strong consistency across writes
- Transactional support (multi-table atomicity)
- Ad-hoc query flexibility (SQL joins)
Engineering — Incidents & Decisions.md
Decision
Use managed Postgres as the primary datastore.
Schema migrations are managed via Alembic. Engineering — Incidents & Decisions.md
Alternatives Considered
| Option | Outcome | Reason for rejection |
|---|---|---|
| MongoDB | ❌ Rejected | No reliable transactions and joins; unsuitable for relational data |
| DynamoDB | ❌ Rejected | Operational lock-in and weak ad-hoc query support |
| Postgres | ✅ Chosen | Strong consistency, SQL flexibility, transaction support |
Engineering — Incidents & Decisions.md
Consequences
Benefits accepted:
- Strong consistency guarantees
- Full SQL flexibility (joins, ad-hoc queries)
- ACID transactions across tables
Costs accepted:
- Manual schema migrations (managed via Alembic)
Engineering — Incidents & Decisions.md
Decision Map
Related Pages
- Engineering Overview — system map and service index
- Postmortem: 2026-05-12 API Outage — incident where connection pool exhaustion exposed a risk in Postgres connection management
- Runbook: Roll Back a Bad Deploy — procedure relevant when a Postgres-touching deploy goes wrong (note: schema migrations require special care before rollback)