Postgres runs LLMs in database
- JigsawStack pushed an open-source project called postgres-llm that lets PostgreSQL triggers enqueue LLM jobs and write results back into rows automatically. - The notable detail is architectural, not scale — v2 adds async execution with `pg_cron`, a queue table, retries, and multi-column updates. - That matters because it turns AI enrichment into plain SQL plumbing, but keeps the usual database tradeoffs around latency, ops, and lock-in.
Postgres is starting to absorb one more job that usually lives in application code. This time it’s LLM calls. JigsawStack’s open-source `postgres-llm` project wires AI inference directly into PostgreSQL triggers, so an insert or update can enqueue a model call and later write the answer back into the same row. That sounds small, but it changes where a lot of “AI workflow” code lives. (github.com) ### What actually shipped? The project is `postgres-llm`, published by JigsawStack and documented by Interfaze. The core idea is simple — create a trigger, point it at a prompt, and tell Postgres which column or columns should receive the result. A new review row can come in with `review_text`, and a few seconds later the same row gets a `sentiment` value without any separate worker service you had to write yourself. (github.com) ### Why is the async part the real news? Because synchronous triggers are a bad place to wait on a model API. The newer version moves work into a queue table and processes it asynchronously with `pg_cron`, so the original `INSERT` can return immediately. That is the difference between a neat demo and something a real app might tolerate in production. The repo also adds retry logic, dedupin(github.com) ### How does it work under the hood? Basically, the trigger function captures the changed row, extracts any values referenced in the prompt with `{column_name}` placeholders, and writes a job into `llm.queue`. A background job then picks up pending rows, calls an OpenAI-compatible chat API over Postgres’s `http` extension, and updates one or more target columns when the response comes back(github.com)hts inside the Postgres engine” — it is model invocation orchestrated from inside the database. (github.com) ### Why would anyone want this in SQL? Because a lot of AI product work is really data-enrichment plumbing. Translate this field. Classify that support ticket. Extract text from an image URL. Summarize a note. If the data already lands in Postgres, doing the enrichment there can remove an app server hop, a queueing layer, and a bunch of glue code. The nice part is that the workflow stays close to the transactional record that triggered it. (github.com) ### Haven’t people done AI in Postgres already? Yes — but there are layers to that story. PostgresML has pushed the “ML inside Postgres” idea for a while, and Timescale’s `pgai` connects PostgreSQL workflows to open-source models through Ollama. What’s different here is the narrowness of the abstraction. `postgres-llm` is not trying to turn Postgres into a full ML platform. It is a trigger(github.com)rstand, and maybe easier to adopt, for teams already living in Supabase-style stacks. (github.com) ### What’s the catch? The catch is that “inside Postgres” is partly a framing trick. The database is orchestrating the call, but the model still lives behind an external API unless you swap in a compatible local endpoint. You also inherit database-shaped operational risks — extension support, background job management, prompt failures, and the awkwardness of mixing transactional systems with slow, probabilistic services. (interfaze.ai) ### Where this gets interesting The interesting part is not that SQL can now call an LLM. That has been possible in different forms already. The interesting part is that the pattern is getting packaged into something tiny and composable — trigger, queue, update, done. If that holds up, AI enrichment starts looking less like a separate subsystem and more like another database side effect. (github.com) ### Bottom line? This is a small project, not a new Postgres standard. But it points at a real shift — developers increasingly want AI tasks to happen where their data already lands, not in a second stack they have to babysit. `postgres-llm` makes that idea concrete. (github.com)
