2.2 KiB
ADR 0001: PostgreSQL/PostGIS instead of SpacetimeDB
- Status: accepted
- Date: 2026-07-18
Context
The system needs durable relational transactions, geospatial proximity queries, authentication data, chat history, trust/audit records, background jobs, Ecto integration, and horizontal Phoenix/Oban nodes.
SpacetimeDB was considered because its server-authoritative realtime model is interesting for live applications.
Decision
Use PostgreSQL with PostGIS as the system of record, Ecto for persistence, Oban for durable jobs, and Phoenix PubSub/Presence for transient realtime fan-out.
Evidence
At the time of this decision, SpacetimeDB's official language support does not list an Elixir server module or client SDK. Its PGWire documentation describes Simple Query support and limitations around parameterized queries, user transactions, catalogs, and roles. Those constraints do not match a conventional Ecto/Oban application. Its self-hosted deployment documentation describes a standalone process, while replicated operation is a different deployment offering.
These are integration constraints, not a general judgment that SpacetimeDB is inferior.
Consequences
- The application uses well-supported Ecto and PostGIS queries.
- Database-backed Oban coordinates multiple worker replicas.
- Phoenix clients reload durable state after PubSub loss or reconnect.
- A single local PostgreSQL container is not described as highly available.
- Production database HA, backups, and recovery are an operational concern separate from web/worker horizontal scaling.
- SpacetimeDB can be reconsidered for a bounded realtime subsystem if official Elixir/Ecto-compatible integration and deployment needs change.