jeeybee
Show HN: Pgnudge – tell your app which Postgres tables just changed
https://github.com/janbjorge/pgnudge
Hello HN!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...
Show HN: Pgnudge - tell your app which Postgres tables just changed
https://github.com/janbjorge/pgnudge
Genuinely unsure if this is crazy or cool: looking for feedback.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...
Show HN: PgQueuer v1.0 – Python job queue using only PostgreSQ
https://github.com/janbjorge/pgqueuer
PgQueuer is a Python job queue that uses PostgreSQL for everything — queue storage, locking, notifications. No Redis, no RabbitMQ, no separate broker to operate. If your app already has Postgres, you already have the broker.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!
Re:Show HN: Rekal – Long-term memory for LLMs in a single SQLite file
on Tuesday April 14, 2026 @02:13AM (#47761872)
Added a mcp command for it, but i might add it as a comfig as well?
Re:Show HN: Rekal – Long-term memory for LLMs in a single SQLite file
on Monday April 13, 2026 @05:10PM (#47757864)
Thanks, i will look into making them configurable.
Re:Show HN: Rekal – Long-term memory for LLMs in a single SQLite file
on Monday April 13, 2026 @05:10PM (#47757862)
The 0.4/0.4/0.2 weights are just based of hand wavy trail an error, will look into other options. I could make them configurable?
Re:Show HN: Rekal – Long-term memory for LLMs in a single SQLite file
on Monday April 13, 2026 @02:16AM (#47748255)
Thanks! You're right, that's just a relic of my dev environment. Will broaden the version requirement.
Show HN: Rekal – Long-term memory for LLMs in a single SQLite file
https://github.com/janbjorge/rekal
I got tired of repeating myself to my LLM every session. rekal is an MCP server that stores memories in SQLite and retrieves them with hybrid search (BM25 + vectors + recency decay). One file, local embeddings, no API keys.
Re:Keeping a Postgres Queue Healthy
on Saturday April 11, 2026 @03:07PM (#47733155)
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?
Re:Show HN: Pglens – 27 read-only PostgreSQL tools for AI agents via MCP
on Monday March 30, 2026 @02:37PM (#47578003)
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.
Re:Show HN: Pglens – 27 read-only PostgreSQL tools for AI agents via MCP
on Monday March 30, 2026 @01:00PM (#47576853)
Thanks! Read-only felt like the obvious constraint; agents shouldn't need write access to understand a database.
Re:Show HN: Pglens – 27 read-only PostgreSQL tools for AI agents via MCP
on Sunday March 29, 2026 @12:31PM (#47564630)
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.
https://github.com/janbjorge/pglens
pip install pglen
Show HN: Pglens – 27 read-only PostgreSQL tools for AI agents via MCP
Show HN: Pglens – Postgres MCP server that lets agents look before they query
Show HN: GYML – YAML syntax, JSON semantics, zero runtime dependencies
https://github.com/janbjorge/gyml
YAML keeps surprising people in production. The Norway Problem (`NO` parsed as `False`). Silent duplicate key overwrites. The spec has 211 grammar productions. Most of that complexity exists to support features nobody wanted in a config file.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...
Show HN: PgQueuer – A PostgreSQL job queue that works without PostgreSQL
https://github.com/janbjorge/pgqueuer
PgQueuer turns PostgreSQL into a background job queue using LISTEN/NOTIFY and FOR UPDATE SKIP LOCKED. v0.26.0 adds an in-memory adapter so you can run the same code in tests and CI without a database. Internally it's now built on port protocols, so you can swap the persistence layer entirely.EDIT; HN trims the full url to readme about in-memory...
Show HN: Jqueue: A job queue that runs on a single JSON file
https://github.com/janbjorge/jqueue
I built a Python job queue that stores its entire state in one JSON file on S3, GCS, or your filesystem. No Redis, no RabbitMQ, no Postgres. Just object storage.How it worksRead 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
PGQueuer for High-Performance Job Queues
Re:Using PostgreSQL as a Dead Letter Queue for Event-Driven Systems
on Monday January 26, 2026 @06:03AM (#46764198)
I maintain a small Postgres-native job queue for Python called PGQueuer: https://github.com/janbjorge/pgqueuer
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.
Re:Kafka is Fast – I'll use Postgres
on Wednesday October 29, 2025 @05:58PM (#45753628)
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.
Repo: https://github.com/janbjorge/pgqueuer
Disclosure: I maintain PGQueuer.
Re:Slack has raised our charges by $195k per year
on Thursday September 18, 2025 @07:27AM (#45288302)
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.
Re:Ask HN: What are you working on? (July 2025)
on Monday July 28, 2025 @08:35AM (#44710219)
pgqueuer turns vanilla PostgreSQL into horizontally-scalable job queue with zero extra infrastructure. If you’re running Postgres and want to ditch extra queue clusters, give it a spin and let me know how it holds up.
Ask HN: How Do You Approach Public Docs for Small Open-Source Projects?
Hi HN,I’m the maintainer of PGQueuer, a minimalist job queue for Python that runs entirely on PostgreSQL—no Redis, brokers, or additional infrastructure required. It’s designed to offer solid concurrency with low overhead and fit seamlessly into projects that already use Postgres.I’ve been working on improving the public documentation [1], and I’m looking for feedback from others who’ve gone...
Someoen accidentally saved half a million-dollars
Re:Ask HN: Can You Prompt an LLM to Solve a Simple Puzzle Clearly?
on Sunday April 13, 2025 @07:24AM (#43671967)
I've observed something interesting: my toddler can quickly and somewhat effortlessly solve a simple physical puzzle, yet when I try to prompt large language models (LLMs) to guide me clearly through the solution, they struggle.
Even with clear photographs and detailed instructions, LLMs tend to give general advice or indirect methods rather than precise, actionable steps that clearly demonstrate correctness.
Have you tried something similar? Have you successfully "prompt-engineered" an LLM into giving clear, precise, step-by-step solutions for physical puzzles? If yes, what's your approach?
Ask HN: Can You Prompt an LLM to Solve a Simple Puzzle Clearly?
Re:Performance of the Python 3.14 tail-call interpreter
on Monday March 10, 2025 @03:31AM (#43317836)
Kudos to the author for diving in and uncovering the real story here. The Python 3.14 tail-call interpreter is still a nice improvement (any few-percent gain in a language runtime is hard-won), just not a magic 15% free lunch. More importantly, this incident gave us valuable lessons about benchmarking rigor and the importance of testing across environments. It even helped surface a compiler bug that can now be fixed for everyone’s benefit. It’s the kind of deep-dive that makes you double-check the next big performance claim. Perhaps the most thought-provoking question is: how many other “X% faster” results out there are actually due to benchmarking artifacts or unknown regressions? And how can we better guard against these pitfalls in the future?
Gitlab: Account Takeover via Password Reset
Re:Why young parents should focus on building trust with their kids
on Thursday February 13, 2025 @05:45AM (#43034662)
This post is a perfect reminder of Gandhi’s advice: "Be the change you want to see in the world." We can’t expect kids to trust or wait for better outcomes unless we first model consistency and patience ourselves. Our everyday actions—keeping promises, showing reliability—are the real lessons that shape their future.