SQLStreams

the messaging platform that is just Postgres

You last visited on 9999-99-99 Show what's new since then
Posted: 2026-09-11 · Report this thread
brandon Site Admin brandon profile Posts: 677

SQLStreams is early, in the open, and built in deliberate layers — each one proven against integration tests over a real Postgres and an hour-long benchmark run that ends in one verdict before the next goes on top. This page is the honest state of the world: what ships today, what’s in flight, and what waits for a real workload to demand it.

Built: the engine

The core described throughout these docs is shipped, not planned:

  • One immutable message log per stream, per-group delivery state beside it — the architectural keystone. Retention, independent fan-out, and per-group dead-lettered messages all fall out of that split.
  • Transactional produce — your business writes and the message in one COMMIT. The full guide →
  • The message lifecycle — claims, leases, retries with backoff, dead-lettering, and a per-attempt audit trail (lifecycle →).
  • Routing-key bindings — a consumer group declares which messages it receives (routing →).
  • Log compaction — opt a message into a key whose claims only ever see the latest version.
  • Partition-based retention — the message log is partitioned by id range; expiry is a DROP, not a million-row DELETE.
  • The maintenance fleet — partition upkeep, cursor advancement, expired-lease reclaim, schedules, and default alerts run embedded in every consumer, or standalone via sqlstreams manager run.
  • Diagnostics as a system — every error and operator-facing log event carries a SQL code with a docs page; sqlstreams explain works offline; the CLI speaks --output json throughout.
  • A migration compatibility gate — every schema step declares the oldest library version that can run against it, checked at migration time (upgrades →).

Now: measured numbers

Every number on this site cites a recorded run; the benchmarks page holds the sustained-throughput result and how to reproduce it. The current work is the lab itself — one command that runs a whole scenario, native or in Compose — and then recovery under load: a chosen fault, the backlog it leaves, and how long the drain takes.

Next: the v1 surface

The public-surface review is complete. The API reference retains batching, transaction controls, and resource-specific migration operations. Shared client construction state and diagnostic declarations now have explicit ownership; SQL owner-column helpers live outside the supported client surface.

The remaining documentation audit covers defaults, shutdown requirements, errors, and destructive effects on the retained handles and instances. The entry package’s future location is still undecided. v1 means the surface stops moving.

Implementation packages remain importable for advanced use, outside the supported API boundary.

Later: what a workload has to earn

These are designed-but-not-built, picked up when a real deployment demands them rather than on speculation:

  • Circuit breaker — per-instance trip with group-wide coordination, so a dead downstream doesn’t dead-letter a backlog.
  • Header routing — attribute-set matching (region=eu AND tier=gold) beside the routing key.
  • Producer wake-ups via LISTEN/NOTIFY — today consumers poll; wake-on-produce is designed but waits for polling latency to be a measured problem.
  • Lease heartbeats — progress-based lease renewal for handlers whose legitimate runtime exceeds the work timeout.
  • An HTTP API — produce via POST, consume via SSE, for languages without a Postgres driver in hand.

What we want from you

This site exists to collect opinions, and the questions we’re actively weighing:

  1. Would you adopt this for a new project? If not, what’s the missing piece — a language SDK, a benchmark, a migration path, a managed offer?
  2. Which pitch lands harder? “a job queue you’ll never outgrow,” or “producing in your own transaction kills your worst class of bugs.”
  3. Where’s your line for Postgres-as-queue? What throughput or retention number would make you reach for Kafka anyway?
  4. A managed offering: would you pay for operations on top of open source, or do you only trust fully managed (database included)?

Open an issue, or just reply to whoever sent you this link — they’ll make sure it reaches us.