Another insane Jev use case! Traditional database filters need precise, predefined conditions. But many questions are semantic: - Is this article mainly about software engineering? - Which topic best describes it? - How technically deep does it appear? These usually require moving rows into application code, invoking a model,... parsing its output, and writing the result back. pg-jev is an open-source Postgres extension that exposes Jev through SQL functions. - jev() works inside WHERE - jev_prob() returns a probability - jev_choice() selects a label - jev_score() ranks rows across ordered levels. It needs no vector column or embedding index. Under the hood, pg-jev batches rows, sends them to Jev, and returns typed answers that SQL can filter, sort, group, and combine with exact predicates. The recording below runs it against real Hacker News stories stored in Postgres. It first shows the rows, then asks Jev to find software-engineering stories, classify them by topic, and rank them by technical depth. The final query reports requests, tokens, cost, and cache hits from the database session. GitHub repo: (don't forget to star it ⭐) Postgres keeps the data and controls the query, while Jev handles the part SQL cannot express as a deterministic condition. If you want to understand what Jev is doing under the hood, I also wrote a hands-on guide to building a Jev-style model with open models, entirely locally. Read it below.show more

Nice demo. A few practical details from the pg-jev docs and measurements that are worth knowing before trying this on real data: On a 2,000-row table the cold first pass took about 3.5 s and ~$0.012 (≈296k input tokens). The same condition from the session cache dropped to ~50 ms, and a fresh condition with LIMIT 3 finished in ~0.6 s because the read-ahead can stop early. Batches are capped at 20 rows; ground-truth checks showed 100 % agreement up to that size and a clear drop past ~25–40. It is a full scan of whatever the executor still asks about, so cheaper predicates in the same WHERE (age > 40 AND jev(…)) prune rows before they are sent. Requires Postgres 14–17 with plpython3u and superuser privileges, so managed hosts (Supabase, Neon, RDS, etc.) cannot run it. Row contents go to the TypeSafe API.

Checked out the repo, really interesting idea! Could see an LLM turning “how many users liked our latest changes?” into SQL with Jev calls to classify their feedback and count the results. I’ve been using Jev in Entune to pick suitable dictionary replacements for dictation instead of blindly replacing words. Fun to see it used inside Postgres too.

i read it as peg jev

I like this for exploring data, but I'd keep a model outage away from customer-facing queries. Would you materialize the labels for production, or run Jev live in WHERE?

jev seem to have wider use cases than llm due to its narrowness, speed and cost

The Ganesha logo is cool and also apt :) Nice one

ngl keeping semantic classification directly inside the sql planner instead of pulling rows into python memory is so clean

Batching affects probability

I’d compare those topic and relevance decisions with GLiDE. It beats Jev on Decision Index retrieval, 60.9 vs 55.4, and overall, 64.81 vs 57.91. Would be interesting to see which Hacker News rows the two models disagree on.

/me was baking

Does the semantic filter call the model once per row at query time?

Local decision engines show how language models can power deterministic database workflows.

told my boss i'd never have to learn sql and was right again.

asking postgres questions in plain english is the only way db work should feel. every other extension sells me a vector index and calls it a day

@garrytan Gbrain might use this?

so you just bolted an llm onto the query planner and called it a feature. where's the cost breakdown for real traffic though, that video shows a demo not a bill

Semantic search is the real game-changer here. It’s not just about keywords anymore—understanding intent and context is what makes Jev so powerful.

I literally put a plan to build a jev based postgres linter and verifier yesterday, thanks for sharing!

peg jev... need a NSFW spoiler plz

something new on Jev ecosystem

Does that even cache the results of the Jev evaluation? If not then it could be pretty huge waste of money with enough users 😁

This is where LLMs inside databases start getting really interesting

Did you really added LLM to works inside SQL query? ;)

SQL casually asking “is this technical?” is kinda crazy lol

Semantic filters inside SQL are an interesting fit. How do you handle borderline classifications—set a probability threshold, or keep an “uncertain” bucket?

@grok kindly ping for me the relevant PMs of for this killer feature: Provide us a post filtering capability where you use jev to filter out dumb hype posts like these Thank you

Jev is goated my friend

Inline scoring is not reproducible: a model hiccup becomes a query outage, and rows move as the model version changes. Materialize label plus probability.

把模型调用塞进查询路径，延迟从毫秒变秒级，事务超时和连接池会先炸。适合离线打标回写，不适合在线过滤。

这种语义筛选放进数据库里，倒是能省掉不少来回搬数据的活。

could this become an alternative to classic vector search or RAG systems? How fast/costly is this on a bigger database?

What I like is the judgment staying next to the data. I've watched teams export rows to a script, classify, write back, and the labels drift from the source within a week. Curious how you audit a WHERE clause that is really a probability though.

how does Jev handle the nuances in semantic questions like topic depth?