Jev and DuckDB: Plain-English Conditions in SQL

Say you have a Parquet file of 50,000 support tickets and want to know which customers are angry. A LIKE pattern won't find that. The usual options are to label data and train a classifier, or to send each row to a chat LLM and parse the text it returns. The first takes work up front. The second is slow and costs more per row.

On September 15, 2026, TypeSafe AI introduced Jev, a model that answers this kind of question with a typed value and a probability instead of a paragraph. Within a week, Hamilton Ulmer posted on X that he had built a DuckDB extension that classifies about 1,000 rows from any CSV, Parquet file or table in roughly ten seconds. Other DuckDB extensions appeared over the next few days.

This post describes what Jev is, how the extensions work and where to read more.

What Jev Is

Jev is what TypeSafe calls a System One model: you send it a state and a set of questions, and it returns typed answers with calibrated probabilities. It never generates a sentence. In the launch post, founder Diogo Almeida (who worked on the research behind ChatGPT at OpenAI) describes it as a function call backed by frontier intelligence. The name refers to Kahneman's fast System 1 thinking and to the economist William Stanley Jevons.

There are three question types, and each corresponds to something SQL already has:

TypeSafe quotes 70–500 ms end-to-end latency and $0.042 per million input tokens, with output tokens free. All questions in a request are evaluated in parallel, so asking five questions about a row takes little more time than asking one. The launch post lists "map-reducing over big data" as a target use case, which is the kind of work people use DuckDB for.

For independent context, The New Stack's launch coverage covers the $40 million seed round. LangChain's post on building a harness with Jev shows where it fits inside an agent loop. Hyperstack's deep dive reproduces the scoring mechanism on an open model and checks TypeSafe's speed claims against LangChain's benchmark. Note that the headline 190× speedup figures come from TypeSafe's own workflow evals.

pg-jev and the DuckDB Ports

The first SQL integration was for Postgres. On September 17, Zachi posted pg-jev on X: a jev() function that turns a plain-English condition into a WHERE clause, with no index and no embeddings. His demo judged 129 rows in about a second for under a tenth of a cent, and you can try it on mock tables in the pg-jev live demo. The source is on GitHub. Four days later, Actian hired him.

DuckDB ports followed within days. The closest to the original is judoaseeta/duckdb-jev, which keeps pg-jev's function names.

Installation

With the exception of the jev community extension, most of the extensions are not yet distributed through the community extensions repository, so you build them yourself and load them as unsigned extensions. For the rest of the post, we'll use the jev community extension. To install and load it, run:

INSTALL jev FROM community;
LOAD jev;

The jev community extension is supported in DuckDB v1.5.5 and v1.5.6.

Then set your TypeSafe API key, which you can get from the TypeSafe console after registering and topping up your account:

SET jev_api_key = '...';

The extension must be built for the exact DuckDB version and platform you run.

An Example

Warning All of the extensions in this post send row contents to a third-party API. Do not use them on data you are not allowed to share.

Let's start with filtering using the person table of the LDBC SF0.1 dataset.

-- Filter: a boolean predicate
CREATE TABLE person AS
FROM 'https://blobs.duckdb.org/data/ldbc-sf0.1-person.parquet';

SELECT id, firstName, lastName
FROM person
WHERE jev(person, 'the name is European')
LIMIT 5;

┌────────────────┬───────────┬──────────┐
│       id       │ firstName │ lastName │
│     int64      │  varchar  │ varchar  │
├────────────────┼───────────┼──────────┤
│           1129 │ Carmen    │ Lepland  │
│ 10995116278700 │ Joseph    │ Anderson │
│ 28587302322727 │ Steve     │ Moore    │
│ 30786325578904 │ Giuseppe  │ Donati   │
│  6597069766983 │ A. C.     │ Bos      │
└────────────────┴───────────┴──────────┘

In a ticketing system, you could rank, classify or score the tickets as follows:

-- Rank: a probability you can sort on
SELECT subject, jev_prob(tickets, 'the customer is angry') AS p
FROM tickets
ORDER BY p DESC
LIMIT 20;

-- Classify: one of a fixed set of labels
SELECT
    jev_choice(tickets, 'which team should handle this?',
               ['billing', 'technical', 'security', 'sales']) AS team,
    count(*)
FROM tickets
GROUP BY 1;

-- Score: a position on an ordered rubric
SELECT
    name,
    jev_score(products, 'how luxurious is this product?',
              ['budget', 'mid-range', 'premium', 'luxury']) AS luxury
FROM products
ORDER BY luxury DESC;

Because jev() returns a boolean, it works with the rest of SQL. If you add a cheaper condition such as age > 40 in the same WHERE clause, it runs first, and rows it rejects are never sent to the API. A LIMIT stops the scan early, and jev_max_rows_per_statement caps the spend.

The video “I Tested Jev with DuckDB. It's 1.8x Faster Than Haiku.” demonstrates plain-English SQL queries in DuckDB and compares Jev's speed with Claude Haiku. The 1.8× figure is from one test.

The DuckDB Extensions

Several people built these extensions independently, and they made different choices about batching, caching and output types.

DuckDB passes rows to an extension in chunks of up to 2,048, which suits batched API calls. The recodelabs extension groups each chunk by question and options, skips identical rows and sends the rest in batches across jev_concurrency threads. It retries 429s and 5xx errors with exponential backoff.

Batching makes a large difference to speed. The prasanthj extension reports a 0.211 s median for 100 nested JSON rows sent in batches of 25, compared with 16.8 s one row at a time. A 2,049-row run took under a second. The author notes these timings come from one local run on synthetic data. Larger batches may cost accuracy, though: pg-jev's docs report that accuracy drops above roughly 20–25 rows per request, so test batch sizes on your own data.

Colliber's version uses Jev's typed output directly. Choice options are defined in advance, so the result can be a DuckDB ENUM rather than text that needs parsing. The prasanthj build can evaluate nested JSON, STRUCT, LIST and ARRAY values without exporting them to Python.

Some replies under Hamilton Ulmer's post point out that a fine-tuned ModernBERT is still cheaper once training is amortized, and that treating classification as embedding retrieval can reach about 20,000 rows per second on CPU. Jev makes most sense when you have no labeled data and a new question to ask. For a fixed classification task at high volume, a trained model may be cheaper and faster.

Conclusion

Jev returns a BOOLEAN, an ENUM or an ordinal score, and DuckDB can filter, group and sort on all three. With these extensions, you can write a condition in English and use it alongside joins, GROUP BY and window functions.

Jev is in early access behind a waitlist, the extensions are days old and unsigned, and most performance numbers come from their own authors. Start on a small, non-sensitive sample, watch your usage counters and compare against a baseline before you trust the labels. If you build something with Jev and DuckDB, the extension authors welcome issues and pull requests on their repositories.

Further Reading

• Introducing System One Models & Jev (TypeSafe AI's launch post)
• TypeSafe launched Jev because sequential LLMs are “totally useless for computers” (The New Stack)
• What Is Jev? A Guide to TypeSafe AI's System One Model (LangChain blog)
• Jev: TypeSafe AI's First System One Decision Model (Hyperstack)
• I Tested Jev with DuckDB. It's 1.8x Faster Than Haiku. (YouTube)
• Calling Jev from SQL (YouTube)
• pg-jev launch post and live demo (Zachi)
• Hamilton Ulmer's DuckDB extension post (X)