jevql

How we reviewed this: we ran its Go test suite in Docker offline — nine packages, all green. We made no Jev calls.

What it does

jevQL, by Kyle McLaren, gives you jev(), jev_prob() and friends in ordinary SQL:

SELECT name, city, jev_prob(people, 'could work from home') AS p
FROM people
WHERE jev(people, 'could work from home')
ORDER BY p DESC;

The trick is that the database never sees those functions. jevQL parses the statement, lifts the jev_* calls out, runs the remaining SQL, judges the returned rows in batches, and applies the predicate afterwards. So it works against managed Postgres where you can’t install an extension — the alternative approach taken by pg_typesafe and duckdb-jev.

It ships more surface than its star count suggests: a CLI, an HTTP and MCP node, Go, TypeScript and Python SDKs, a cache, and a rewrite package with its own tests. All nine test packages pass offline.

What to know

Rows are sent to TypeSafe in batches, as structured state, with no redaction. That’s the trade for not needing an extension: the judging happens outside the database, so the data goes with it.

There’s also real machinery here — a SQL parser and rewriter — and any bug in that sits between you and your query. The tests are reassuring; the scope isn’t small.

Verdict

The right answer for managed Postgres, and a tidy implementation: batching by default, a cache, several front ends, and tests covering the parse and rewrite paths rather than just the client.

If you control the server, an in-database extension keeps the rows where they are. If you don’t, this is how to get the same query shape.

For that comparison, see pg_typesafe.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.