I found my self always doing some kind of polling loop for my applications when i want to watch data as it comes in, however i find striking the balance between aggressive polling and the responsiveness tricky.

So i wrote (with help from claude) pgnudg. pgnudge is a small async Python library that wakes your app when specific Postgres tables change. It only tells you which tables moved. You refetch, and the database stays the source of truth.It reads the WAL over the replication protocol and turns commits into per-table wakeup

I am more than willing to acknowledge that this is properly overkill, but I found it interesting, and maybe some else might as well?

Comments URL: https://news.ycombinator.com/item?id=48969927

Points: 1

# Comments: 0

pgnudge is a small async Python library that tells you which tables just changed in Postgres, so a cache or read model can refetch the moment the data moves. No row data - it tells you when and what to reload, you already know how to load it.

It leaves nothing persistent on the server (temp replication slot, dropped when the session ends) and needs no database driver — it speaks the walsender protocol itself. One dependency.

Not CDC (no before/after rows), not a queue (no durability). It moves wakefulness, not rows or work.

Repo: https://github.com/janbjorge/pgnudge

Comments URL: https://news.ycombinator.com/item?id=48883032

Points: 3

# Comments: 0

After ~2 years and 26 minor releases, 1.0 ships today as the first stable release. Strict semver from here on.

Thanks to everyone who contributed and left feedback!

Comments URL: https://news.ycombinator.com/item?id=48100177

Points: 2

# Comments: 0

https://github.com/janbjorge/rekal/pull/14/changes

Comments URL: https://news.ycombinator.com/item?id=47744683

Points: 9

# Comments: 10

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.

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.

https://github.com/janbjorge/pglens

pip install pglen

Comments URL: https://news.ycombinator.com/item?id=47564620

Points: 13

# Comments: 7

Comments URL: https://news.ycombinator.com/item?id=47494195

Points: 3

# Comments: 0

GYML is a strict subset of YAML. Valid GYML is always valid YAML. It keeps the block indentation syntax and pairs it with JSON's type semantics: one spelling for each type, no anchors, no aliases, no tags, duplicate keys are a hard error. From-scratch parser, no runtime dependencies, fully typed Python.

https://github.com/janbjorge/gyml

Comments URL: https://news.ycombinator.com/item?id=47302509

Points: 1

# Comments: 0

EDIT; HN trims the full url to readme about in-memory https://github.com/janbjorge/pgqueuer?tab=readme-ov-file#in-...

Comments URL: https://news.ycombinator.com/item?id=47210945

Points: 2

# Comments: 0

How it works

Read the JSON file, modify it in memory, write it back with compare-and-set. If two workers race, one wins. The loser retries with fresh state. No locks needed.

Inspired by; https://turbopuffer.com/blog/object-storage-queue

Comments URL: https://news.ycombinator.com/item?id=47144842

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47094172

Points: 1

# Comments: 0

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.

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.

Repo: https://github.com/janbjorge/pgqueuer

Disclosure: I maintain PGQueuer.