JavaScript in einer Open-Source-Datenbank schließt spezifische SQL-Lücken
JavaScript in der relationalen Open-Source-Datenbank, die von vielen Webanwendungen genutzt wird, wird als eng begrenzte Erweiterung von SQL positioniert und nicht als Möglichkeit, eine Anwendung in die Datenbank zu verlagern. Percona beschrieb den Ansatz am 15. Oktober 2026 nach Vorführungen eines JavaScript language component auf der Percona Live Europe 2026. Dabei handelt es sich um eine V8-basierte Engine für Perconas Open-Source-Datenbankserver 8.4. V8 ist die Software-Engine, die JavaScript in Chrome und Node.js ausführt.
Diese Unterscheidung ist wichtig, weil Datenbankadministratoren gute Gründe haben, in Datenbanken eingebetteter Anwendungslogik zu misstrauen. Große Sammlungen von stored procedures, also wiederverwendbaren Programmen, die von einer Datenbank ausgeführt werden, können schwierig zu testen, zu versionieren, einem Verantwortlichen zuzuweisen oder auf mehrere Server zu verteilen sein. Die von Percona vorgeschlagene Grenze besteht darin, dass SQL, die Sprache für Abfragen relationaler Datenbanken, Mengen von Zeilen verarbeitet, während JavaScript einen einzelnen Wert oder eine eng begrenzte Berechnung bearbeitet.
Die runtime setzt einen Teil dieser Grenze durch. Eine mit dem JavaScript language component erstellte routine hat keinen Netzwerkzugriff, kann keine Methoden für Netzwerkanfragen oder sockets verwenden und weder einen Zahlungsanbieter noch einen microservice kontaktieren. Sie hat keinen Zugriff auf das file system, kann keine Konfigurationsdateien oder keys lesen und stellt weder Node.js- noch Browser-DOM-APIs bereit. Es gibt keine Funktion zum Laden von Modulen, kein process interface und kein npm-Paketökosystem. Außerdem erfolgt die Ausführung synchron und nicht auf sinnvoll nutzbare Weise asynchron. Diese Einschränkungen verhindern, dass die routine wie ein herkömmlicher Anwendungsdienst arbeitet.
Stattdessen können JavaScript functions aus Klauseln für Datenabruf, Tabellenverknüpfung, Filterung und Gruppierung oder aus einem trigger aufgerufen werden. Ein trigger ist Datenbankcode, der automatisch ausgeführt wird, wenn bestimmte Datenänderungen stattfinden. Perconas Beispielfunktion zur key-Normalisierung durchläuft rekursiv ein JSON-Dokument, wandelt object keys in Kleinbuchstaben um und gibt den transformierten Wert zurück. JSON ist ein strukturiertes Textformat für Objekte und Listen. Die function wird als JavaScript verwendend sowie als deterministisch und ohne SQL-Ausführung deklariert. Das bedeutet, dass derselbe input denselben output erzeugen sollte, ohne SQL auszuführen oder externe side effects zu verursachen.
Die vorgesehenen Einsatzgebiete sind Operationen, die sich mit SQL nicht bequem ausdrücken lassen. Dazu gehört die rekursive Untersuchung von JSON, dessen Struktur nicht im Voraus bekannt ist, da bei der JSON table facility die paths ausdrücklich angegeben werden müssen. Weitere Beispiele sind Algorithmen, die arrays benötigen, welche SQL nicht als nativen Datentyp bereitstellt, sowie Berechnungen, die das 19-stellige Limit des large-integer type überschreiten, etwa eine IBAN mod-97 checksum mit einer 29-stelligen Zahl. Weitere Anwendungsfälle sind iterative Berechnungen mit aggregates, weil eine recursive CTE weder eine aggregate function noch eine window function enthalten kann und die Fehlernummer 3575 zurückgibt, sowie eine umfassendere Textverarbeitung als mit einfachen Funktionen für Groß- oder Kleinschreibung, beispielsweise um das große D in McDonald beizubehalten. Eine recursive CTE ist eine query, die wiederholt das eigene vorherige Ergebnis verwendet.
Vier Vorführungen veranschaulichten dieselbe Arbeitsteilung. Die Normalisierung von JSON keys reduzierte einen Partnerbericht von 51 Zeilen und vier kombinierten query branches auf 19 Zeilen, ohne Partnernamen einzubetten. In einer Vorführung zur Eingabevalidierung formatierten functions Namen, E-Mail-Adressen und Telefonnummern, überprüften eine IBAN und stellten bereinigte Kontaktdaten zusammen. Sie erkannten Probleme in 460 von 2.000 Zeilen und gaben für jede betroffene Zeile eine Fehlerliste zurück. Die Datenbank konnte fehlerhafte Eingaben einheitlich ablehnen, doch die Entscheidung, einen abgelehnten Kontakt zu korrigieren, unter Quarantäne zu stellen oder weiterzuverfolgen, blieb der Anwendung überlassen.
Die Vorführung zur Deduplizierung verwendete Levenshtein distance, eine Zählung der Bearbeitungen einzelner Zeichen, die erforderlich sind, um einen string in einen anderen umzuwandeln. Der Vergleich von 3.000 bestehenden Kunden mit 2.000 Registrierungen würde sechs Millionen mögliche Paare erzeugen. SQL predicates auf Grundlage von Stadt und Initialen reduzierten diese Menge zunächst auf 21.352 Paare, und nur diese candidates erreichten die JavaScript function für die Distanzberechnung. In Perconas Demoergebnissen fand ein exakter Namensabgleich 21,7 Prozent der Duplikate, während SQL-Filterung in Kombination mit zwei Distanzberechnungen rund 80 Prozent bei einer Präzision von 99,7 Prozent fand. Die function erzeugte einen score; ob zwei customer records zusammengeführt werden sollten, blieb eine Entscheidung außerhalb der Datenbank.
Eine geografische Berechnung zeigte die potenziellen Kosten eines wiederholten Wechsels zwischen einer prozeduralen SQL-Schicht und dem query executor. SQL window functions wandelten 44.347 unbearbeitete Reisestopps in 16.232 gewichtete endpoints um. Anschließend führte JavaScript den inner loop einer Weiszfeld procedure aus, um einen geometrischen Median zu bestimmen. Danach ordneten gewöhnliche joins die Koordinate einem Bezirk zu. Percona meldete für prozedurales SQL eine Laufzeit von 11,00 Sekunden und 327.033 statements, verglichen mit 0,52 Sekunden und sechs statements für JavaScript. Ein procedure call las 16.232 Zeilen und schrieb 2.000 Antworten, ohne Ergebniszeilen über das Netzwerk zu übertragen. Percona führt die Verbesserung darauf zurück, dass 327.033 Wechsel zum executor vermieden wurden, und nicht darauf, dass JavaScript grundsätzlich schneller sei.
Diese geografische Demo verwendete das session SQL interface, weshalb sie derzeit in der Enterprise Edition des Datenbankservers läuft. Die SQL-Ausführung aus JavaScript wurde als wichtigster Punkt auf der roadmap für Percona Server bezeichnet. In der aktuellen Komponente werden JSON columns als native JavaScript objects übergeben, wodurch ein gesondertes parsing vermieden werden kann. routines sollten dennoch nur die Zeilen erhalten, die sie tatsächlich benötigen. Das Beispiel zur Deduplizierung zeigt, warum vorheriges Filtern unverzichtbar ist: Der Aufruf einer custom function für jedes mögliche Paar würde die Stärke von SQL bei der Eingrenzung großer datasets zunichtemachen.
Percona schlägt fünf Tests vor, um zu entscheiden, ob Code in eine database routine gehört. Er sollte mit Werten arbeiten, die bereits von der Datenbank gespeichert werden, deterministisch und frei von Auswirkungen außerhalb der transaction sein, von SQL aufgerufen werden, die Menge der zurückgegebenen Daten reduzieren oder einen network round trip vermeiden und eine Regel umsetzen, die jeder client befolgen muss. Validierung, parsing, checksums, similarity scores, die Umformung von JSON und der inner loop einer numerischen Berechnung können diese Tests erfüllen. Workflows, Freigaben, Benachrichtigungen, authentication, user sessions, externe API-Aufrufe und häufig wechselnde Produktrichtlinien gehören in die Anwendung. Wenn configuration tables, feature flags oder ein anderes System benötigt werden, ist das ein Warnsignal dafür, dass eine routine diese Grenze überschritten hat.
Darüber hinaus gibt es betriebliche Kontrollen. Entwickler können die function zusammen mit dem SQL einreichen, das sie aufruft, während Datenbankadministratoren ihre Filterung und die erwartete Anzahl der Aufrufe prüfen. Zusätzlich zur Berechtigung zum Erstellen einer routine ist die Berechtigung zum Erstellen einer JavaScript routine erforderlich. Dadurch kann die Erlaubnis zum Schreiben von JavaScript routines ausdrücklich vergeben werden. Definitionen von routines sollten neben schema migrations in der Versionsverwaltung aufbewahrt werden. Deterministische functions ohne verborgenen state lassen sich zudem mit gewöhnlichen unit-testing methods testen.