I think that'd be cool, maybe just a simple config option in pyproject.toml or a .rekal/config.yml would cover most use cases: they could default to 0.4/0.4/0.2 but could be overriden.
Did you test with fillfactor < 100 on the queue table? With HOT updates, status changes can reuse dead space without creating new index entries, which seems like it could significantly delay the onset of the death spiral?
If the status column changes, and an index depends on the contents of that status column (be it by referencing it in its columns, or in the index's WHERE filter) then an update of the status column will prevent the HOT optimization from being applied.
No config step, the tools discover everything from pg_catalog at call time. list_schemas → list_tables → describe_table is the typical agent workflow, and there's a query_guide prompt baked in that suggests that progression.
On query guardrails: every query runs in a readonly transaction and results are capped at 500 rows via a wrapping SELECT * FROM (...) sub LIMIT 500. There's also explain_query which returns the plan without executing, so agents can check before running something expensive. That said, there's no cost-based gate that blocks a bad plan automatically; that's an interesting idea worth exploring.
Most Postgres MCP servers expose query and list_tables. Agents end up guessing column values, enum casing, and join paths - then retrying until something works.
pglens gives agents the context to get it right the first time: column_values shows real distinct values with counts, find_join_path does BFS over the FK graph and returns join conditions through
intermediate tables, describe_table gives columns/PKs/FKs/indexes in one call. Plus production health tools like bloat_stats, blocking_locks, and sequence_health.
Everything runs in readonly transactions, identifiers escaped via Postgres's quote_ident(), no extensions required. Works on any Postgres 12+ (self-hosted, RDS, Aurora, etc.). Two dependencies:
asyncpg and mcp.
It uses the same core primitives people are discussing here (FOR UPDATE SKIP LOCKED for claiming work; LISTEN/NOTIFY to wake workers), plus priorities, scheduled jobs, retries, heartbeats/visibility timeouts, and SQL-friendly observability. If you’re already on Postgres and want a pragmatic “just use Postgres” queue, it might be a useful reference / drop-in.
If you like the “use Postgres until it breaks” approach, there’s a middle ground between hand-rolling and running Kafka/Redis/Rabbit: PGQueuer.
PGQueuer is a small Python library that turns Postgres into a durable job queue using the same primitives discussed here — `FOR UPDATE SKIP LOCKED` for safe concurrent dequeue and `LISTEN/NOTIFY` to wake workers without tight polling. It’s for background jobs (not a Kafka replacement), and it shines when your app already depends on Postgres.
Nice-to-haves without extra infra: per-entrypoint concurrency limits, retries/backoff, scheduling (cron-like), graceful shutdown, simple CLI install/migrations. If/when you truly outgrow it, you can move to Kafka with a clearer picture of your needs.
I’ve always loved Slack. It’s been core to how we work, and I’ve recommended it to countless others.
But seeing how they just treated Hack Club — sudden 40x price hike, almost no notice, threatening to cut off access and delete 11 years of history — makes me wonder if we should rethink where we build our work.
I don’t want to leave Slack. But I also don’t want to wake up one day with our team’s history held hostage.
