Zachi ends pg-jev, says query speed breaks above 50k rows
The Postgres extension works under 50k rows and stops being useful above that, by its own author's measurement.
Zachi has called the newest release of pg-jev its last, saying the Postgres extension will not work as expected. The cutoff he gives is 50k rows. Under that, he says it is fine. Above it, query speed is the bottleneck.
Under 50k rows its fine, but for everything above that, query-speed is a bottleneck here.
Spent about 3b tokens for benchmarks and testing and its safe to say that pg-jev wont work as exptected.
The number comes out of roughly 3 billion tokens spent on benchmarks and testing, by his own account. That is the whole of the evidence in public right now. There is no published table of latencies per row count, no comparison against running the same classification outside the database, and no breakdown of which part of the path is slow. So treat the 50k figure as one builder's measurement on his own workload rather than a property of Jev or of Postgres.
What this actually rules out
The shape being retired here is the per-row call inside a SQL query, where every row in a result set triggers a Jev decision and the query cannot finish until all of them come back. That pattern is appealing precisely because it is invisible, you write one SELECT and the classification happens in the engine. The cost of the pattern is that it hides a per-row network and inference cost inside something that looks like a scan, and it scales exactly as badly as that implies.
This is the second public argument against per-row calls in the space of a few days. Shreya Shankar made a related case earlier, on query planning grounds rather than measured latency. Zachi's post is the empirical version, from someone who shipped the extension and then benchmarked it until he decided to stop shipping it.
What comes next is a claim, not a result
Zachi says he is building a replacement that will be faster, smarter, and usable in the database of your choice, naming Supabase, Neon and Drizzle, and that it will still use TypeSafe AI. None of that has numbers attached yet. It is a plan posted alongside the postmortem, and it should be read that way.
For people building on it, the practical read is narrow. If your Postgres tables are small and the classification is a nice-to-have on a few thousand rows, pg-jev was fine and the last release still exists. If you were planning to point it at a production table and let it grow, that plan now has an author-stated ceiling and no maintenance path behind it. Anyone already running it past 50k rows should check their own query times rather than wait for the successor, because the successor is currently a sentence in a tweet.