Saltar a contenido

ADR-002: PostgreSQL como state store único

  • Status: Accepted
  • Date: 2026-05-14
  • Tags: core, storage, infrastructure

Context and Problem Statement

El engine necesita un state store para: - Append-only command log - Event log - Process instances state (current state, tree, variables) - Jobs queue - User tasks - Incidents - Auth/tenant data

Camunda 8 usa RocksDB embedded + Elasticsearch para search/UIs (doble store). ¿Replicamos este pattern, o consolidamos en un solo store?

Decision Drivers

  • Operational simplicity (mantener 1 store vs 2)
  • Real-time visibility (vs eventually consistent del export pipeline)
  • Cost (menos infra)
  • Backup/restore atomic (vs coordinated cross-system)
  • Replication, HA, sharding maduros
  • Postgres team-friendly (skill común vs RocksDB/ES expertise raro)

Considered Options

  1. PostgreSQL único — tablas para todo
  2. RocksDB embedded + Elasticsearch (Camunda 8 pattern)
  3. Postgres + Redis (state en PG, cache en Redis)
  4. Postgres + Elasticsearch (state en PG, search en ES)
  5. Embedded DB (SQLite) — single-node only

Decision Outcome

Chosen option: PostgreSQL único porque: - Throughput suficiente para el MVP (375 TPS reportado por Intuit con Camunda 8 — Postgres rinde ~70% según docs oficiales, ~260 TPS — más que suficiente para Phase 0/1) - Real-time queries (no export lag) - Ecosystem maduro: Patroni, pgBackRest, Citus, WAL-G - Team skills: SQL es universal - Backup atomic single tool

Positive Consequences

  • 50%+ reducción en infra (no ES cluster, no RocksDB tuning)
  • Real-time visibility para Operate/Tasklist (advantage vs Camunda)
  • Backup/restore con pg_basebackup atomic
  • Replication, HA, sharding heredados del ecosystem
  • SQL queries ad-hoc para analytics (cubre 80% de Optimize)
  • Tooling estándar (Grafana, pgAdmin, psql, etc.)

Negative Consequences

  • Performance ceiling menor que RocksDB (microsegundos vs milisegundos)
  • Sin full-text search avanzado de ES (Postgres FTS es decent pero no equivalente)
  • Single-store scaling más caro a escala extrema (>100K TPS)
  • Connection management requiere PgBouncer en Phase 1+

Pros and Cons of the Options

PostgreSQL único

Pros: - Single store to operate - ACID transactions atomic (state + log) - Mature ecosystem (Patroni, pgBackRest, Citus, WAL-G) - SQL queries ad-hoc - Real-time consistency - Backup atomic - Team skill común

Cons: - Performance ceiling menor que RocksDB - Postgres FTS < ES advanced search - Scaling muy alto (>100K TPS) requiere Citus o sharding

RocksDB + Elasticsearch (Camunda 8)

Pros: - Performance extrema (microsegundos en RocksDB) - ES search avanzado (aggregations, full-text) - Probado a 22M instances/15h (Intuit)

Cons: - 2 stores a operar (50%+ más complejidad ops) - ES expensive (25-50% throughput reduction documented) - Eventually consistent (export lag) - Backup coordinated cross-system - RocksDB tuning requires expertise

Postgres + Redis

Pros: - State durable, cache rápido - Patterns familiares

Cons: - Cache invalidation complexity - 2 stores - Real-time gain marginal vs Postgres con índices buenos

Postgres + Elasticsearch

Pros: - ES search avanzado donde lo necesites - Postgres como source of truth

Cons: - Sigue siendo 2 stores - Export pipeline overhead - ES cost ongoing

SQLite embedded

Pros: - Zero ops - WAL mode performance decent

Cons: - Single-node only (no HA path) - No concurrent writers - Scaling limit muy bajo