{"slug": "pgque", "name": "pgque", "category": "databases", "category_name": "Databases", "description": "", "recommenders": 4, "commenters": 5, "warners": 0, "score": 3.849, "rising": -1.31, "first": "2026-04-30", "latest": "2026-07-30", "why": "My team has been starting to use PgQue [1] for a new application, and it seems really well-designed.", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 4, "neutral": 0, "compare": 1, "warn": 0}, "spark": [0, 0, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "My team has been starting to use PgQue [1] for a new application, and it seems really well-designed.", "kind": "", "icon": false, "domain": null, "github_repo": "github.com/nikolays/pgque", "official_url": "https://github.com/NikolayS/pgque", "pricing": "", "aliases": ["pgque", "PgQue"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 785851664, "item_id": 49115729, "url": "https://news.ycombinator.com/item?id=49115729", "by": "atombender", "date": "2026-07-30", "version": null, "stance": "recommend", "quote": "My team has been starting to use PgQue [1] for a new application, and it seems really well-designed.", "excerpt": "A performance pitfall that isn't addressed in the DBOS article at all is the bloat problem: If you update or delete rows that you consume, dead tuples start to accumulate due to Postgres' way of doing MVCC. This is a serious problem because it affects the planner's ability to make good choices. Dead tuples are still indexed and the need to skip them isn't accounted for by the query planner, so a table with lots of de", "context": "team building a new application", "use_case": "Postgres queue without bloat", "switched_from": "", "story": "Postgres Queues Actually Scale"}, {"id": 778671106, "item_id": 48666944, "url": "https://news.ycombinator.com/item?id=48666944", "by": "dewey", "date": "2026-06-24", "version": null, "stance": "recommend", "quote": "There's great projects like", "excerpt": "> There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Because in 99% of cases you don't need a purpose built solution (Even if engineers often think that) at the scale that most people operate in. Nothing is easier to setup and administer than the database you already use. We are using Postgres as a worker queue in production for many years, with mil", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 773093680, "item_id": 48318355, "url": "https://news.ycombinator.com/item?id=48318355", "by": "banditelol", "date": "2026-05-28", "version": null, "stance": "recommend", "quote": "I like what pgque does", "excerpt": "For some interesting alternative for postgres as queue (actually more like kafka log), I like what pgque does https://github.com/NikolayS/pgque rather than using select for updates and other semantic, it uses snapshot and table truncate to reduce bloat. I havent used it for my dayjob but the different approach is refreshing to see and interesting for different system trade off.", "context": "", "use_case": "Postgres-based message queue", "switched_from": "", "story": "Just Use Postgres for Durable Workflows"}, {"id": 767525553, "item_id": 47970347, "url": "https://news.ycombinator.com/item?id=47970347", "by": "ahachete", "date": "2026-04-30", "version": null, "stance": "recommend", "quote": "I'd recommend benchmarking the recently announced PgQue project", "excerpt": "> we find a Postgres server can handle up to 144K of these writes per second. That\u2019s a lot, equivalent to 12 billion writes per day. Based on the shown graph, this is misleading at best, essentially false. After 120K writes/s p50 spikes from 10ms to 1s (1 second for a write!!!!). That's two orders of magnitude latency spike, and an unacceptable one for an OLTP workload. It clearly shows the server is completely satur", "context": "", "use_case": "Postgres queue", "switched_from": "", "story": "Does Postgres Scale?"}]}], "caveats": [], "who": [{"by": "atombender", "context": "team building a new application", "url": "https://news.ycombinator.com/item?id=49115729", "date": "2026-07-30"}], "tags": [], "use_cases": ["postgres queue without bloat", "postgres-based message queue", "postgres queue"], "compared": [{"slug": "postgresql", "name": "PostgreSQL", "co": 3, "switched_from": 0, "switched_to": 0}, {"slug": "apache-kafka", "name": "Apache Kafka", "co": 3, "switched_from": 0, "switched_to": 0}], "makers": [{"id": 765149888, "item_id": 47821868, "url": "https://news.ycombinator.com/item?id=47821868", "by": "samokhvalov", "date": "2026-04-18", "version": null, "stance": "recommend", "quote": "PgQue can still be a replacement in certain cases", "excerpt": "Fair. I had an attempt to clarify it in README that PgQue is \"closer to Kafka topics than to a job queue\" -- per-subscription cursor on a shared event log, no ACK-delete, no visibility timeout. That makes PgQue an event-streaming tool, not an MQ. For SKIP LOCKED systems like PGMQ, PgQue can still be a replacement in certain cases \u2013 similarly to how Kafka can be a replacement for RabbitMQ or ActiveMQ in certain cases.", "context": "", "use_case": "", "switched_from": "", "story": "PgQue: Zero-Bloat Postgres Queue"}], "threads": [{"url": "https://news.ycombinator.com/item?id=49113913", "title": "Postgres Queues Actually Scale", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=48666433", "title": "PostgreSQL Is Enough", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=48313530", "title": "Just Use Postgres for Durable Workflows", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47966625", "title": "Does Postgres Scale?", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47817349", "title": "PgQue: Zero-Bloat Postgres Queue", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {}, "2026-03": {}, "2026-04": {"recommend": 1}, "2026-05": {"recommend": 1}, "2026-06": {"recommend": 1}, "2026-07": {"recommend": 1, "compare": 1}, "2026-08": {}, "2026-09": {}, "2026-10": {}}, "versions": [], "version_unnamed": 0, "family_ref": null, "runs_on": null, "lines": [], "quotes": [{"id": 785902528, "item_id": 49118908, "url": "https://news.ycombinator.com/item?id=49118908", "by": "NightMKoder", "date": "2026-07-30", "version": null, "stance": "compare", "quote": "more like Kafka in Postgres", "excerpt": "You can go deeper and model a queue as a ring-esque buffer with a write head (can just be a serial id) and a read head. The read head starts at the same place as the write head and advances only up to the write head and no further via nextval(). The main benefit is you now remove the lock contention as many workers attempt to dequeue at once. The super advanced version of this is pgque - https://pgque.dev/ - but that", "context": "", "use_case": "", "switched_from": "", "story": "Postgres Queues Actually Scale"}, {"id": 785851664, "item_id": 49115729, "url": "https://news.ycombinator.com/item?id=49115729", "by": "atombender", "date": "2026-07-30", "version": null, "stance": "recommend", "quote": "My team has been starting to use PgQue [1] for a new application, and it seems really well-designed.", "excerpt": "A performance pitfall that isn't addressed in the DBOS article at all is the bloat problem: If you update or delete rows that you consume, dead tuples start to accumulate due to Postgres' way of doing MVCC. This is a serious problem because it affects the planner's ability to make good choices. Dead tuples are still indexed and the need to skip them isn't accounted for by the query planner, so a table with lots of de", "context": "team building a new application", "use_case": "Postgres queue without bloat", "switched_from": "", "story": "Postgres Queues Actually Scale"}, {"id": 778671106, "item_id": 48666944, "url": "https://news.ycombinator.com/item?id=48666944", "by": "dewey", "date": "2026-06-24", "version": null, "stance": "recommend", "quote": "There's great projects like", "excerpt": "> There are lots of purpose-built bullet proof queuing systems that are simple to setup and administer (or just use SQS). Because in 99% of cases you don't need a purpose built solution (Even if engineers often think that) at the scale that most people operate in. Nothing is easier to setup and administer than the database you already use. We are using Postgres as a worker queue in production for many years, with mil", "context": "", "use_case": "", "switched_from": "", "story": "PostgreSQL Is Enough"}, {"id": 773093680, "item_id": 48318355, "url": "https://news.ycombinator.com/item?id=48318355", "by": "banditelol", "date": "2026-05-28", "version": null, "stance": "recommend", "quote": "I like what pgque does", "excerpt": "For some interesting alternative for postgres as queue (actually more like kafka log), I like what pgque does https://github.com/NikolayS/pgque rather than using select for updates and other semantic, it uses snapshot and table truncate to reduce bloat. I havent used it for my dayjob but the different approach is refreshing to see and interesting for different system trade off.", "context": "", "use_case": "Postgres-based message queue", "switched_from": "", "story": "Just Use Postgres for Durable Workflows"}, {"id": 767525553, "item_id": 47970347, "url": "https://news.ycombinator.com/item?id=47970347", "by": "ahachete", "date": "2026-04-30", "version": null, "stance": "recommend", "quote": "I'd recommend benchmarking the recently announced PgQue project", "excerpt": "> we find a Postgres server can handle up to 144K of these writes per second. That\u2019s a lot, equivalent to 12 billion writes per day. Based on the shown graph, this is misleading at best, essentially false. After 120K writes/s p50 spikes from 10ms to 1s (1 second for a write!!!!). That's two orders of magnitude latency spike, and an unacceptable one for an OLTP workload. It clearly shows the server is completely satur", "context": "", "use_case": "Postgres queue", "switched_from": "", "story": "Does Postgres Scale?"}]}