{"slug": "pg-jev-query-postgres-in-plain-english-with-a-decision-model", "title": "PG-Jev: Query Postgres in Plain English With a Decision Model", "summary": "PG-Jev, a Postgres extension distributed through PGXN, lets developers filter, rank, and classify database rows using plain English conditions inside SQL queries, sending the semantic work to a decision model rather than regex or keyword lists. A demo on a customer support ticket table ranked ten tickets by \"anger score,\" routed tickets to billing, technical, shipping, and security, and scored urgency from low to critical with a single SQL query and no training data or rule lists, with every classification correct. The extension requires an API key and model configuration set inside the Postgres session, defaults to the latest available model when no model name is given, and can point at any OpenAI-compatible endpoint, though it is built around the Jev decision model.", "body_md": "# PG-Jev: Query Postgres in Plain English With a Decision Model\n\nPG-Jev lets you filter, rank, and classify Postgres rows using plain English inside SQL. Here's how it works and how to install it.\n\n## What is PG-Jev?\n\nPG-Jev is a Postgres extension that lets you filter, rank, and classify database rows using plain English conditions written directly inside SQL queries. Instead of writing regular expressions, keyword lists, or shipping data out to application code for an LLM call, you write a `where` clause or a scoring function in natural language, and the extension sends the semantic work to a decision model behind the scenes. The database stays the system of record. The model handles the part of the logic that SQL was never designed to express, things like “is this customer angry” or “which department should handle this ticket.”\n\nIt’s distributed through PGXN, the Postgres Extension Network, which functions like npm but for Postgres: a public registry where developers publish and install extensions with a lightweight client tool.\n\n## TL;DR\n\n- **PG-Jev is a Postgres extension** that runs semantic filtering, ranking, and classification inside SQL using plain English instead of keyword matching or regex.\n- **It installs through PGXN** , the Postgres Extension Network, using a small client tool that works similarly to npm for Node packages.\n- **It needs an API key and model configuration** set inside your Postgres session; if you skip the model name it defaults to the latest available model, and any OpenAI-compatible endpoint can be pointed at it, though the extension is built around the Jev decision model.\n- **A demo on a customer support ticket table** showed it ranking tickets by “anger score,” auto-routing tickets to departments (billing, technical, shipping, security), and scoring urgency from low to critical, all with a single SQL query and zero training data or rule lists.\n- **Every classification in the demo was correct** : a charge dispute went to billing, suspicious account activity went to security, a wrong shipment went to shipping, and a crashing app went to technical.\n- **You don’t strictly need this specific extension** to get the behavior; the same result is achievable by wrapping any capable model (local or API-based) in a tool call or an MCP server and connecting it to any database, not just Postgres.\n- **The core value is replacing a chunk of application logic** (routing engines, triage systems, sentiment scoring) with one query, cutting out the infrastructure that a hand-built classification pipeline would otherwise need.\n\n## Other agents ship a demo. Remy ships an app.\n\nReal backend. Real database. Real auth. Real plumbing. Remy has it all.\n\n## How does PG-Jev work inside a SQL query?\n\nPG-Jev exposes a function, demonstrated in the source video as `jev_probe` (used inside a `select` or `where` clause), that takes a piece of text, in this case a support ticket, and a plain English condition, like “is this customer angry or frustrated,” and returns a usable score or classification. That score can be used to order results, filter rows, or feed into further logic, all inside standard SQL syntax.\n\nThe workflow demonstrated looked like this:\n\n1. Create a table (the demo used a customer support tickets table with columns for ticket text and the usual metadata).\n2. Call the PG-Jev function in a `select` statement, passing the row’s text and a natural language question.\n3. Order or filter based on the returned score.\n\nIn the ticket-ranking example, the query asked for an anger score across ten tickets with no predefined categories and no keyword rules. The results put a crashing app and a disputed charge at the top, with a happy customer and a feature request at the bottom, matching how a human reviewer would prioritize the same queue. The same pattern worked for department routing (billing, technical, shipping, security) and for urgency scoring, where a flagged suspicious account activity ticket scored close to critical while a feature request scored at zero.\n\n## How do you install PG-Jev on Postgres?\n\nThe installation process shown runs on Ubuntu and assumes a working Postgres setup. The broad steps:\n\n- Install Postgres itself (the demo used version 14.24) and confirm it’s running with a version check.\n- Install Python support for Postgres, since the extension relies on it.\n- Install `pip` if it isn’t already present.\n- Install the PGXN client, a lightweight command line tool used to pull extensions from the PGXN registry, similar in spirit to how `npm install` pulls JavaScript packages.\n- Use the PGXN client to install the Jev extension, then run `create extension` inside your Postgres database to activate it.\n- Set an API key and model name as configuration variables inside the Postgres session. If no model name is set, the extension defaults to the latest available model.\n\nOne detail worth flagging: the extension supports any OpenAI-compatible API key, which means it’s possible to point it at a locally hosted model server rather than a hosted API, as long as that server exposes an OpenAI-compatible endpoint. That said, the extension itself is built specifically to work with the Jev decision model family.\n\n## Is PG-Jev worth using over writing your own classification pipeline?\n\nThis is the honest tension in the whole idea, and it’s one the creator raises directly: you don’t need this specific extension to get this specific result. The same semantic classification can be built by wrapping any capable model, local or hosted, in a tool call or an MCP server, and pointing that wrapper at any database engine (Postgres, MySQL, SQL Server, Oracle, whatever you’re running). PG-Jev isn’t doing something structurally impossible to replicate outside of it.\n\nWhat it does offer is convenience and locality. The logic lives inside the database layer instead of a separate application service. There’s no need to stand up a routing microservice, write a prompt orchestration layer, or move ticket data out to an external pipeline just to get a sentiment score. For teams already comfortable writing SQL, being able to drop a plain English condition into a `where` clause removes a layer of custom infrastructure that would otherwise take real engineering time to build and maintain, particularly for something like a support ticket routing engine that normally touches rules, keyword dictionaries, and ongoing maintenance as categories shift.\n\nThe tradeoff is the usual one for any LLM-in-the-loop system: every row scored this way triggers a model call, which means latency and cost scale with query size, and the classification quality depends entirely on the decision model behind it. For small to medium tables and operational queries like ticket triage, that’s a reasonable cost. For scanning millions of rows on every query, it’s a different calculation.\n\n## What are realistic use cases for semantic SQL filtering?\n\nThe demo centered on customer support, but the pattern generalizes to any text-heavy table where categories are fuzzy or evolving:\n\n- **Sentiment and urgency scoring** on support tickets, reviews, or survey responses, ranking by how upset or urgent something is rather than by a fixed tag.\n- **Automatic routing or classification** of unstructured text into departments, categories, or priority tiers without maintaining a keyword list or training a dedicated classifier.\n- **Ad hoc filtering** of rows using conditions that would otherwise require complex regex or multiple joined lookup tables, like “find all entries that sound like a security concern.”\n\nIn each case, the appeal is collapsing what would normally be a small classification service, or a batch job calling an LLM API, into a query that a backend engineer can write and iterate on in minutes.\n\n## Frequently Asked Questions\n\n### What is PGXN and why does it matter here?\n\nPGXN, the Postgres Extension Network, is a public registry for Postgres extensions, comparable to npm for Node.js packages. PG-Jev is distributed through it, and its lightweight client tool is used to find and install the extension directly from the command line.\n\n### Do I need an API key to use PG-Jev?\n\nYes. You configure an API key and, optionally, a model name as settings inside your Postgres session. If no model name is specified, the extension defaults to the latest available model.\n\n### Can PG-Jev work with locally hosted models?\n\nThe extension accepts any OpenAI-compatible API key and endpoint, which opens the door to pointing it at a self-hosted model server. However, it’s designed around the Jev decision model specifically.\n\n### Does PG-Jev require training data or predefined categories?\n\nNo. In the demonstrated examples, ticket routing, anger scoring, and urgency scoring were all done using plain English instructions with no keyword lists, no regex, and no prior training data.\n\n### Is this the only way to get semantic filtering in a database?\n\nNo. The same outcome can be achieved by wrapping any capable language model in a tool call or an MCP server and connecting it to a database, Postgres or otherwise. PG-Jev packages that pattern as a native Postgres extension for convenience, not as the only route to the result.", "url": "https://wpnews.pro/news/pg-jev-query-postgres-in-plain-english-with-a-decision-model", "canonical_source": "https://www.mindstudio.ai/blog/pg-jev-postgres-plain-english-queries/", "published_at": "2026-10-09 00:00:00+00:00", "updated_at": "2026-10-09 10:53:14.825378+00:00", "lang": "en", "topics": ["ai-tools", "ai-products", "large-language-models", "developer-tools"], "entities": ["PG-Jev", "Postgres", "PGXN", "Jev", "OpenAI", "Remy"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/pg-jev-query-postgres-in-plain-english-with-a-decision-model", "markdown": "https://wpnews.pro/news/pg-jev-query-postgres-in-plain-english-with-a-decision-model.md", "text": "https://wpnews.pro/news/pg-jev-query-postgres-in-plain-english-with-a-decision-model.txt", "jsonld": "https://wpnews.pro/news/pg-jev-query-postgres-in-plain-english-with-a-decision-model.jsonld"}}