Was ist pg-jev?
pg-jev ergänzt PostgreSQL um SQL-Funktionen wie jev(), jev_prob(), jev_choice() und jev_score(). Schreibst du WHERE jev(tickets, 'the customer is angry'), wird jede Zeile an TypeSafes Jev geschickt, ein Entscheidungsmodell, das statt generiertem Text eine kalibrierte Wahrscheinlichkeit liefert. Es gibt keinen Index, kein Embedding und keine Vektorspalte; es ist bewusst ein Full Scan.
Die Erweiterung ist in PL/Python geschrieben. Sie liest die Tabelle voraus, packt 20 Zeilen pro Anfrage, hält bis zum Doppelten der Concurrency-Einstellung (standardmäßig 16) gleichzeitig offen und cacht Antworten für die Sitzung. Das README misst für eine Tabelle mit 2.000 Zeilen beim ersten Lauf etwa 3,5 Sekunden und 0,012 $, mit Cache etwa 50 ms. Der Endpoint lässt sich auf einen lokalen Jev-kompatiblen Server wie stuntd richten, sodass Zeilen das Netz nie verlassen.
Das Projekt stammt von einem einzelnen Entwickler, steht unter der PostgreSQL Licence, wurde im September 2026 angelegt und hat etwa 1.238 Sterne und 13 Commits. Das neueste Release ist v0.2.1 (3. Oktober 2026), auch auf PGXN veröffentlicht.
Lohnt sich pg-jev?
pg-jev macht eine eng umrissene Aufgabe angenehm: Fragen zu Zeilen, die sich in SQL nicht ausdrücken lassen, etwa ob ein Ticket mit Kündigung droht oder welches Team es übernehmen sollte. Weil jev() eine gewöhnliche boolesche Funktion ist, lässt es sich mit Joins, GROUP BY und LIMIT kombinieren, und billigere Prädikate in derselben WHERE-Klausel laufen zuerst, sodass WHERE age > 60 AND jev(...) nur die übrig gebliebenen Zeilen sendet.
Die technischen Notizen sind besser als bei den meisten Projekten dieser Größe. Der Autor hat gemessen, warum ein Batch 20 Zeilen umfasst: Batches von 1 bis 20 waren gegenüber der Ground Truth vollständig korrekt, bei 40 fiel es auf 92 bis 98 %, bei 80 auf 77 bis 94 %. Das README erklärt auch die Kosten einer kalten Verbindung und dass der Sitzungscache unbegrenzt wächst, bis er geleert wird. (Die Projekt-Website beschreibt noch Batches von 40 und sechs gleichzeitige Anfragen; das README ist neuer.)
Die Grenzen sind struktureller Art. Jede Zeile, nach der der Executor fragt, geht an die API, eine unachtsame Abfrage auf einer großen Tabelle ist also langsam und kostet Geld. Die Erweiterung braucht plpython3u und einen Superuser, was Supabase, Neon, RDS und die meisten Managed-Hosts ausschließt, und ihre Funktionen laufen mit den Betriebssystemrechten des Servers. Zeileninhalte gehen an einen Dritten, sofern du keinen lokalen Server wie stuntd betreibst.
Es ist außerdem sehr jung: 13 Commits, ein Maintainer, keine Commits seit Anfang Oktober. Gegenüber pgvector, das Ähnlichkeitsfragen statt Ja-Nein-Fragen beantwortet, ist pg-jev das richtige Werkzeug für Klassifizierung und Filterung auf überschaubaren Tabellen, und eine Ausgabenbremse wie jev.max_rows_per_statement sollte gesetzt sein, bevor jemand anderes Zugriff bekommt.
Wo es sich lohnt
Eine Support-Leiterin mit 20.000 Tickets in selbst gehostetem Postgres
Die Tickets finden, in denen der Kunde mit Kündigung droht
Erst in SQL nach Datum vorfiltern, dann ORDER BY jev_prob(tickets, ...) LIMIT 50. Beim Satz aus dem README von etwa 0,012 $ pro 2.000 Zeilen kostet ein voller Durchlauf rund 0,12 $, und erneutes Sortieren innerhalb der Sitzung ist kostenlos.
Ein Data Engineer in einer Firma, die keine Kundendaten nach außen geben darf
Eingehende E-Mails an Abrechnung, Technik oder Vertrieb weiterleiten
jev.api_url auf einen lokalen stuntd-Server setzen und jev_choice() mit den drei Optionen aufrufen. Keine Abrechnung pro Zeile, aber die Genauigkeit des lokalen Servers musst du selbst prüfen.
Ein Startup auf Supabase
Den Admin-Abfragen Filter in natürlicher Sprache hinzufügen
Das funktioniert nicht: Managed-Hosts geben weder Superuser noch plpython3u frei. Nötig wäre ein selbst verwaltetes Postgres oder ein separater Dienst, der Jev aufruft.
Bevor du dich festlegst
- Einrichtung
- PostgreSQL 14 bis 17 mit plpython3u und einem Superuser; pgxn install jev oder make install, CREATE EXTENSION jev CASCADE, dann einen TypeSafe-API-Schlüssel setzen. Ein Docker-Image und ein Agenten-Skill für skills.sh sind dabei.
- Integrationen
- Standardmäßig TypeSafes Jev-API; jeder Server, der POST /v1/systemone spricht, etwa stuntd; funktioniert mit Tabellen und Views, Unterabfragen werden mit einer Zeile pro Anfrage beurteilt.
- Daten und Datenschutz
- Zeileninhalte gehen an TypeSafe, sofern jev.api_url nicht anderswohin zeigt; Antworten werden in der Backend-Sitzung gecacht. plpython3u-Funktionen laufen mit den OS-Rechten des Servers. PostgreSQL Licence; nicht mit TypeSafe verbunden.
- Kosten im großen Maßstab
- TypeSafe rechnet pro Token ab: Das README misst beim ersten Lauf etwa 0,012 $ für 2.000 Zeilen. jev.max_rows_per_statement und jev.max_chars_per_statement begrenzen die Ausgaben pro Abfrage.
- Grenzen
- Bewusst Full Scans; die Genauigkeit sinkt oberhalb von etwa 20 bis 25 Zeilen pro Batch; der Sitzungscache ist unbegrenzt, bis er geleert wird; keine Unterstützung für Managed Postgres; ein Maintainer.
Was gut ist
- Filter in natürlicher Sprache, die sich mit normalem SQL kombinieren lassen
- Gemessene Zahlen zu Batching, Caching und Kosten in der Doku
- Ausgabenbremsen pro Statement für geteilte Datenbanken
- Lässt sich auf einen lokalen Jev-kompatiblen Server richten
Was nicht
- Full Table Scan; jede Zeile geht an die API
- Braucht Superuser und plpython3u; kein Managed Postgres
- Zeilendaten verlassen standardmäßig dein Netz
- Ein einzelner Maintainer mit 13 Commits
Am besten für
Analysten und Entwickler auf selbst verwaltetem Postgres, die Tausende Zeilen nach ihrer Bedeutung klassifizieren oder filtern wollen, ohne eine Embedding-Pipeline zu bauen.
Alternativen zu pg-jev
pg-jev: häufige Fragen
- Lohnt sich pg-jev?
- Ein cleverer Weg, einer Tabelle in SQL unscharfe Fragen zu stellen, sofern du einen Full Scan, eine Installation als Superuser und Zeilen, die die Datenbank verlassen, in Kauf nimmst. Wir bewerten es mit 3.7 von 5.
- Was kostet pg-jev?
- Kostenlos (PostgreSQL Licence). Jede beurteilte Zeile rechnet TypeSafes Jev-API ab, sofern du es nicht auf einen lokalen kompatiblen Server richtest.
- Welche Nachteile hat pg-jev?
- Full Table Scan; jede Zeile geht an die API; Braucht Superuser und plpython3u; kein Managed Postgres; Zeilendaten verlassen standardmäßig dein Netz; Ein einzelner Maintainer mit 13 Commits.
- Für wen eignet sich pg-jev?
- Analysten und Entwickler auf selbst verwaltetem Postgres, die Tausende Zeilen nach ihrer Bedeutung klassifizieren oder filtern wollen, ohne eine Embedding-Pipeline zu bauen.
- Was kostet pg-jev für ein Team oder im Produktivbetrieb?
- TypeSafe rechnet pro Token ab: Das README misst beim ersten Lauf etwa 0,012 $ für 2.000 Zeilen. jev.max_rows_per_statement und jev.max_chars_per_statement begrenzen die Ausgaben pro Abfrage.
- Ist pg-jev sicher für Firmendaten?
- Zeileninhalte gehen an TypeSafe, sofern jev.api_url nicht anderswohin zeigt; Antworten werden in der Backend-Sitzung gecacht. plpython3u-Funktionen laufen mit den OS-Rechten des Servers. PostgreSQL Licence; nicht mit TypeSafe verbunden.
- Was sind die besten Alternativen zu pg-jev?
- Die nächsten Alternativen, die wir getestet haben, sind pgvector, AnyJev und Laya.
Antworten geprüft am 31. Okt. 2026.