Event-Driven Architecture With Just Postgres (Until You Really Can't)

Adding a message broker changes your operational surface completely: a new datastore to monitor, back up, upgrade, and secure; new failure modes (topic misconfig, consumer lag, poison messages); new libraries and idioms in every service. It is worth it — but only after you've outgrown the alternatives.

Nearly every event-driven system I've built in the last decade shipped v1 on Postgres and only migrated pieces to Kafka once a concrete constraint showed up. This section is the pattern for v1.

You want to update a row and publish an event about it. The naïve approach — write to the DB, then publish to a broker — has a race: the DB commits, the process crashes, the event is never sent. The outbox pattern makes both writes part of the same transaction.

create table outbox (
  id           bigserial primary key,
  aggregate    text not null,
  aggregate_id uuid not null,
  event_type   text not null,
  payload      jsonb not null,
  created_at   timestamptz not null default now(),
  processed_at timestamptz
);
create index outbox_pending on outbox(id) where processed_at is null;

Every domain write inserts a row into outbox in the same transaction. A worker polls where processed_at is null order by id limit 100, publishes each event to the destination (webhook, another table, an external API), and marks it processed. Because both writes are in one transaction, you never lose an event to a crash between them.

Polling every second is fine at low volume but wastes CPU and adds latency. Postgres has a built-in pub/sub channel:

-- publisher (in the same transaction as the insert)
insert into outbox (...) values (...);
notify outbox_channel, 'new';

-- consumer
listen outbox_channel;
-- your driver will deliver a notification message; then drain the outbox

LISTEN/NOTIFY is fire-and-forget — if no consumer is listening at the moment of NOTIFY, the notification is dropped. That's fine because your consumer's real source of truth is the outbox table; NOTIFY is just a hint that says 'wake up and drain now'. This pattern reliably gets you 50-200ms end-to-end latency.

When another team or system needs a live stream of Postgres changes, logical replication turns Postgres into an event source without your app writing any extra code. Tools like Debezium, pg_kafka_connect, or a homegrown consumer of pg_logical can stream every insert/update/delete as a structured event.

This is the pattern I recommend when a downstream team says 'I need to react to every order change'. You don't build an integration for them — you give them a replication slot and they consume the WAL. Zero coupling in your app code.

Every serious system needs recurring jobs: retention cleanup, aggregation, reminders, health checks. Instead of running a separate scheduler service, install pg_cron and put the schedule next to the SQL it runs.

select cron.schedule('cleanup-old-events', '0 3 * * *', $$
  delete from outbox where processed_at < now() - interval '30 days'
$$);

select cron.schedule('daily-rollup', '10 0 * * *', $$
  insert into daily_metrics select ... from events where day = current_date - 1
$$);

Schedules live in the database, versioned via migrations. Failures are visible in cron.job_run_details. One less service to run.

Postgres event-driven stops being the right answer when you hit one of these:

• You need fan-out to 5+ independent consumers with different processing speeds.
• You need durable log retention past a few days (for reprocessing, ML training, replay).
• You need >10k events/sec sustained per topic — the outbox worker becomes the bottleneck.
• You need multi-region replication with per-region consumers.
• You need ordering guarantees across many partitions.

Even then, migrate one topic at a time. The outbox pattern doesn't disappear — it becomes the source that feeds the broker via a Kafka Connect Debezium sink. Nothing you built is wasted.