Putting a decision next to the data sounds like an optimization. It is really a choice about what the database is allowed to mean. Postgres, DuckDB, and SQLite each have one, and they disagree on batching, safety, and saved answers. The pattern is a semantic filter: rows go in, typed judgments come out, and the database joins them back. The differences are where money and mistakes are.
JEVDB: decisions inside DuckDB
JEVDB is a semantic database on the DuckDB ecosystem. It runs semantic filters, joins, classification, and scoring as ordinary SQL, batches decisions on a Jev model, and returns probabilities, labels, and scores, not explanations. Without key pruning it is JEVDB-Flash; key conditions remove impossible pairs, and a cascade sends uncertain decisions to a second-stage model. An OpenAI-compatible backend works without a Jev account.
The MIT C++ project was created on 2 October 2026. The catalog README is truncated, so the full SQL surface is unevidenced. The paper is more specific. Prune First, Decide Fast reports that JEVDB-Flash has the lowest latency on all 21 SemBench queries and the lowest cost on 19, with competitive answer quality. On Shelob, joins scale to 540K candidate pairs and all queries complete at 95.7%–97.5% mean F1. Semantic Bloom Filters screen out 87.4% of pairs, and condition-index scoring cuts reasoning-model escalations by 55.2%.
The numbers come from the authors' own workloads, and quality is called competitive, not superior. The pruning is the transferable idea: do the cheap relational work first and send only the survivors to the model. That is what the jaggedness page says about counting and arithmetic: keep the exact work in code.
Postgres: a function in the WHERE clause
The pg-jev demo shows the smallest interface: WHERE jev(people, 'could work from home'), or WHERE jev(people, 'name sounds european'). No index and no embeddings; the extension classifies each row against the plain-language condition. In the demo, 129 rows were judged in about a second for $0.0009, with a second run at 6 ms from cache.
The caveat is in the same thread: with no index, judging a condition sends row contents to the API, so a scan of a sensitive table puts that data off-box. The author concedes that 129 rows is not much and says a larger run around 4,500 rows was still being updated. The post does not cover install steps, supported versions, or planner behavior. It is a demo, not a benchmark.
It remains useful. It fits a subjective condition an index cannot express, and fits badly exact totals or access control. Keep those in SQL, and use the function for the genuine judgment.
SQLite: three very different extensions
SQLite has the richest set.
JevSQL is a zero-dependency Node library and CLI that adds jev_bool, jev_choice, jev_match, and jev_pick predicates, plus decision tables saved as ordinary SQLite tables. A materialized decision is queryable without the library or a key. The planner caps a request at 25 states, 120 questions, and 60,000 serialized bytes; maxJudgments defaults to 1,000 per query, and maxEstimatedCostUsd stops before another round. It builds on node:sqlite and needs Node 22.16 or newer.
It is candid about evidence: it has a 31-comparison suite, but two comparisons are deliberately not wins, and the audit says it has no evaluation evidence yet. Keep arithmetic, access control, and writes in code. It is MIT-licensed and not affiliated with TypeSafe. sqlite-jev is a different shape: a loadable C extension and Python package whose jev_rows virtual table batches up to 40 rows per request and returns source_rowid, answer, probability, choice, score, and confidence. It needs SQLite 3.45+ with JSON and loadable extensions, a C11 compiler, libcurl, and TYPESAFE_API_KEY. Settings cover model, batch size, max_rows (500, a spend guard), timeout (90 seconds), and API URL; row contents go to TypeSafe, so prefilter into a temporary table. No license is declared.
sqlite3-jev is the smallest: C functions jev_noul, jev_choice, jev_score, and jev() for several questions in one request, depending only on libcurl. It retries 429 and 529 up to three times and raises API errors as SQL errors, so a 401 aborts the statement. Its README documents no batching or caching, so a scan appears to cost one call per row per function. It is MIT-licensed and can point base_url at tensai for a local GGUF model.
IntentSQL composes small decisions about table, column, comparison, and operand into a typed plan, then compiles deterministic SQL. It reports 93.3% on a held-out clinic schema, 78.0% on 600 Spider questions, and 87.5% when confident: roughly one in eight confident answers is still wrong. It opens a read-only copy; writes preview and require confirmation, with a 100-change cap. The code is MIT; the bundled CS50 databases are CC BY-NC-SA 4.0.
What the database does not decide
| Engine | Interface | Batching | Main risk |
|---|---|---|---|
| DuckDB / JEVDB | SQL semantic filters and joins | Yes, with pruning | Paper results are authors' workloads |
| Postgres / pg-jev | WHERE jev(...) | Not documented | Full scan sends rows to the API |
| SQLite / JevSQL | Predicates plus saved tables | Planner caps | No evaluation evidence yet |
| SQLite / sqlite-jev | jev_rows virtual table | Up to 40 rows | Row contents leave the machine |
| SQLite / sqlite3-jev | Scalar functions | Not documented | One call per row per function |
The pattern that survives all five: prefilter with deterministic SQL, send only the needed columns, cap spend, and join the result by a stable key. The state should be the row or selected fields, not the whole table. A semantic find is often cheaper as an existence check than as a list.
Two jaggedness rules matter in SQL. Counting is unreliable and error grows with size, so do not ask for a total; ask one Noul per row and sum in SQL. Dates are read as text, so extract components with Choice and compare in code. The jaggedness list is a checklist, not a bug report.
Cost and confidence
Every tool turns a query into API calls, so the bill is rows times input size. Batching and pruning are the two levers. The decision-model price war covers per-token economics; locally, a 10,000-row scan with a 2,000-token state is a different product from a 129-row demo.
Confidence belongs in the result. The confidence-gated routing pattern uses a 0.6 floor to route to a human and 0.85 before an irreversible action. Select rows into three buckets (act, review, reject) rather than filtering on the label. A materialized table can carry probability and confidence so code can change the threshold without a re-run.
The models page lists $42 per billion input tokens with free output, a 64k context, and dynamic rate limits. The API reference caps Choice at 255 options and Score at 2–10 levels. A large candidate set needs pre-filtering or multiple passes, which is what key conditions and temporary tables are for.
Choosing a surface
Use DuckDB/JEVDB when the workload is analytical and the joins are hard. Use pg-jev when the predicate is the product and a scan is tolerable. Use JevSQL or sqlite-jev when the result must be a durable table other tools can query. Use sqlite3-jev for the smallest dependency and one call per row.
In every case, pin the model, keep the threshold in SQL, log model and confidence next to the row, and test on a labeled sample first. Designing Around Jagged Edges covers the failure modes, and The Cost of a Decision covers the budget. The database is a good place for a decision because the data is already there. It is a bad place to hide one.
