pg-jev — Jev decisions in SQL

pg-jev is a community Postgres extension (by developer realZachi) that brings Jev into your database. You write a normal query with a jev() call in it — WHERE jev(people, 'the name is European') — and Postgres streams each row to a Jev decision model, asks one typed yes/no, and keeps the rows that pass. Here's how it works and how to point it at a hosted Jev endpoint with your own key.

Filtering rows by meaning usually means pulling them into application code, looping, calling a model, parsing, and filtering there. pg-jev collapses that into the query: the predicate is the decision. Because Jev returns a typed yes/no (a noul) in a single pass rather than generated text, the database gets a clean boolean per row — nothing to parse, nothing to repair.

What it looks like in SQL

-- Keep only the people whose name reads as European.
-- pg-jev sends each row to Jev as a yes/no and filters on the answer.
SELECT *
FROM people
WHERE jev(people, 'the name is European');

-- Works anywhere a boolean does — e.g. tag rows in a projection:
SELECT id,
       jev(reviews, 'this review is a complaint') AS is_complaint
FROM reviews;

Each jev(row, question) call is a single typed decision: the row is the state, your question is a noul, and the result is a calibrated true/false. That's the same primitive the hosted API exposes — pg-jev just moves it into the query planner so you never leave SQL.

Point it at a hosted Jev endpoint

pg-jev needs a Jev endpoint to call. You can point it at the hosted TypeSafe AI gateway with a jv_live_ key — set the endpoint and key in the extension's configuration (see the pg-jev docs for the exact setting names), then every jev() in your SQL resolves against the hosted model:

# A jv_live_ key from the dashboard, and the hosted decide endpoint:
JEV_API_KEY=jv_live_...
JEV_API_URL=https://jevtypesafeai.com/api/v1/decide
# (configure these via pg-jev's settings — see pgjev.com for the exact keys)

Under each jev() call, the extension sends the row as state and your text as a noul question — the same request the code below makes by hand. If you've used the hosted endpoint directly, pg-jev is that call wrapped in a SQL function:

// The hand-written equivalent of one jev(row, question) call:
const res = await fetch("https://jevtypesafeai.com/api/v1/decide", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.JEV_KEY}`, // jv_live_...
  },
  body: JSON.stringify({
    state: row,                       // the Postgres row
    questions: {
      pass: { type: "noul", instructions: "the name is European" },
    },
  }),
});
const { answers } = await res.json();
const keep = answers.pass.noul > 0.5; // WHERE jev(...) is this boolean

Why it's fast enough to put in a query

• Each decision is one non-autoregressive pass — roughly 70–500ms — not a multi-second LLM generation
• The answer is a typed yes/no, so the planner gets a clean boolean with no parsing
• Calibrated confidence (RLCD) means you can threshold instead of trusting a coin flip
• Output tokens are free and each decision is a fraction of a cent — see the pricing page

A caveat worth stating: a jev() predicate calls a model once per row, so it's for meaning-based filters over reasonable row counts, not for scanning billions of rows. Narrow with ordinary SQL first (indexes, WHERE clauses), then let jev() make the judgement call on what's left.

Note on the project

pg-jev is a community extension maintained by its author (realZachi), documented at pgjev.com — it isn't an official TypeSafe product. What this page gives you is the hosted Jev endpoint and key that pg-jev (or your own code) can call. Follow the project's own README for install and the exact configuration settings.

• pgjev.com — The pg-jev project site — install, configuration and SQL reference (community-maintained)

FAQ

See also: Jev API · Jev as a judge · Jev classifier · Semantic Grep · Playground