// the find
zeybek/ulak
PostgreSQL extension for reliable async message delivery to HTTP, Kafka, MQTT, Redis, AMQP & NATS — atomically committed with your transaction, using the transactional outbox pattern
ulak is a PostgreSQL extension that implements the transactional outbox pattern entirely inside the database engine — messages are enqueued atomically with your business transaction and dispatched by background workers to HTTP, Kafka, MQTT, Redis, AMQP, or NATS. It's for teams already running Postgres who want reliable async delivery without adding Debezium, a separate outbox service, or hand-rolled retry logic. At 14 stars it's very early, but the design is sound and the scope is honest.
- The atomic enqueue guarantee is real: `ulak.send()` inside your transaction means no dual-write window. If your INSERT rolls back, the message never existed. That's the whole point of the outbox pattern and it's done correctly here.
- Operational surface is unusually complete for a project this young: circuit breaker, DLQ with redrive, stale-processing recovery, backpressure via `max_queue_size`, and `FOR UPDATE SKIP LOCKED` for worker concurrency are all built in — not left as exercises for the operator.
- The test suite is serious: TAP tests for worker lifecycle, isolation tests for concurrent circuit breaker state and skip-locked behavior, regression SQL tests across all protocol configs, and e2e shell scripts for every adapter. This is more coverage than most production outbox libraries.
- Protocol adapters are compile-time opt-in behind flags like `ENABLE_KAFKA=1`, which keeps the default binary lean and avoids dragging in librdkafka for teams that only need HTTP webhooks.
- Running C code inside the PostgreSQL process space means a bug in ulak can crash your database server, not just drop a message. The README doesn't address this risk at all — no mention of what a segfault in the AMQP dispatcher does to your running transactions.
- The `shared_preload_libraries` requirement is a hard deployment constraint that rules out managed Postgres offerings (RDS, Supabase, Neon, most cloud providers). This isn't mentioned prominently — you'll discover it when you try to install on your production database.
- Fourteen stars and one fork means the maintenance bus factor is essentially one person. The feature set is ambitious (six protocol adapters, circuit breakers, CloudEvents, OAuth2, AWS SigV4) and the surface area for bugs is large relative to the community that would find and fix them.
- Ordering guarantees across workers are unclear in practice. There are isolation tests for `ordering_key` but no documentation on what happens when two workers race on the same key or when a stale-processing recovery interleaves with in-flight messages on the same endpoint.