JavaScript in un database open-source colma lacune specifiche di SQL
JavaScript nel database relazionale open-source utilizzato da molte applicazioni web viene presentato come un'estensione di SQL dall'ambito ben delimitato, non come un modo per trasferire un'applicazione nel database. Percona ha descritto questo approccio il 15 ottobre 2026, dopo le dimostrazioni tenute a Percona Live Europe 2026 di un componente del linguaggio JavaScript, un motore basato su V8 per il database server open-source 8.4 di Percona. V8 è il motore software che esegue JavaScript in Chrome e Node.js.
La distinzione è importante perché i database administrator hanno buone ragioni per diffidare della logica applicativa incorporata nei database. Grandi raccolte di stored procedure, programmi riutilizzabili eseguiti da un database, possono diventare difficili da testare, sottoporre a versioning, assegnare a un responsabile o distribuire su più server. Il confine proposto da Percona prevede che SQL, il linguaggio utilizzato per interrogare i database relazionali, gestisca insiemi di righe, mentre JavaScript gestisce un singolo valore o un calcolo rigorosamente circoscritto.
Il runtime impone una parte di tale confine. Una routine creata con il componente del linguaggio JavaScript non ha accesso alla rete, non può utilizzare metodi per richieste di rete o socket e non può contattare un fornitore di pagamenti o un microservice. Non ha accesso al file system, non può leggere file di configurazione o key e non fornisce le API di Node.js o del DOM del browser. Non sono disponibili funzioni per il caricamento di moduli, interfacce di processo o l'ecosistema di package npm, e l'esecuzione è sincrona anziché utilmente asincrona. Queste restrizioni impediscono alla routine di funzionare come un servizio applicativo convenzionale.
Le funzioni JavaScript possono invece essere richiamate da clausole per il recupero dei dati, la combinazione di tabelle, il filtro e il raggruppamento, oppure da un trigger, ossia codice del database eseguito automaticamente quando si verificano specifiche modifiche ai dati. La funzione di normalizzazione delle key mostrata nell'esempio di Percona attraversa ricorsivamente un documento JSON, converte in minuscolo le key degli oggetti e restituisce il valore trasformato. JSON è un formato di testo strutturato per oggetti e liste. La funzione è dichiarata come basata sul linguaggio JavaScript e come deterministic senza eseguire SQL, il che significa che lo stesso input dovrebbe produrre lo stesso output senza eseguire SQL né creare effetti collaterali esterni.
Gli obiettivi previsti sono operazioni che SQL non riesce a esprimere in modo agevole. Tra queste figurano l'analisi ricorsiva di JSON la cui struttura non è nota in anticipo, poiché la funzionalità JSON table richiede che i path siano scritti esplicitamente; algoritmi che richiedono array, che SQL non offre come tipo nativo; e calcoli che superano il limite di 19 cifre del tipo large integer, come un checksum IBAN mod-97 che utilizza un numero di 29 cifre. Altri esempi comprendono calcoli iterativi con aggregate, perché una recursive CTE non può contenere una aggregate function o window function e restituisce l'errore numero 3575, nonché una gestione del testo più avanzata rispetto alle funzioni di base per maiuscole e minuscole, come la conservazione della D maiuscola in McDonald. Una recursive CTE è una query che utilizza ripetutamente il proprio risultato precedente.
Quattro dimostrazioni hanno illustrato la stessa divisione del lavoro. La normalizzazione delle key JSON ha ridotto un report di un partner da 51 righe e quattro rami di query combinati a 19 righe, senza incorporare i nomi dei partner. In una dimostrazione di validazione dell'input, alcune funzioni hanno formattato nomi, indirizzi email e numeri di telefono, verificato un IBAN e assemblato dati di contatto ripuliti. Hanno identificato problemi in 460 delle 2.000 righe e restituito un elenco di errori per ogni riga interessata. Il database poteva rifiutare in modo coerente l'input sporco, ma la scelta di correggere, mettere in quarantena o effettuare un follow-up su un contatto rifiutato restava una decisione dell'applicazione.
La dimostrazione di deduplication ha utilizzato la Levenshtein distance, ossia il conteggio delle modifiche di un singolo carattere necessarie per trasformare una stringa in un'altra. Il confronto tra 3.000 clienti esistenti e 2.000 nuove registrazioni avrebbe creato sei milioni di coppie possibili. I predicati SQL basati su città e iniziali hanno prima ridotto l'insieme a 21.352 coppie, e solo questi candidati sono stati passati alla funzione JavaScript per il calcolo della distance. Nei risultati della demo di Percona, la corrispondenza esatta dei nomi ha individuato il 21,7% dei duplicati, mentre il filtro SQL combinato con due calcoli di distance ne ha individuati circa l'80% con una precisione del 99,7%. La funzione produceva uno score; la decisione se unire due record di clienti restava esterna al database.
Un calcolo geografico ha mostrato il costo potenziale dei ripetuti passaggi tra un layer SQL procedurale e il query executor. Le window function SQL hanno convertito 44.347 fermate di viaggio grezze in 16.232 endpoint ponderati. JavaScript ha quindi eseguito l'inner loop di una procedura di Weiszfeld per trovare una mediana geometrica, dopodiché normali join hanno associato la coordinata a un distretto. Percona ha riportato 11,00 secondi e 327.033 statement per SQL procedurale, rispetto a 0,52 secondi e sei statement per JavaScript. Una singola chiamata di procedura ha letto 16.232 righe e scritto 2.000 risposte senza trasferire righe di risultati sulla rete. Percona attribuisce il miglioramento all'eliminazione di 327.033 passaggi attraverso l'executor, non a una velocità intrinsecamente superiore di JavaScript.
Quella demo geografica utilizzava l'interfaccia SQL di sessione, il che significa che attualmente viene eseguita nell'enterprise edition del database server. L'esecuzione di SQL da JavaScript è stata indicata come la principale voce della roadmap per Percona Server. Nel componente attuale, le colonne JSON vengono passate come oggetti JavaScript nativi, evitando potenzialmente un parsing separato, ma le routine dovrebbero comunque ricevere soltanto le righe necessarie. L'esempio di deduplication dimostra perché è essenziale applicare prima il filtro: richiamare una custom function per ogni coppia possibile significherebbe rinunciare al punto di forza di SQL nel restringere grandi dataset.
Percona propone cinque test per decidere se il codice debba essere inserito in una routine del database. Dovrebbe operare su valori già memorizzati dal database, essere deterministic e privo di effetti esterni alla transaction, essere richiamato da SQL, ridurre la quantità di dati restituiti o evitare un round trip di rete e implementare una regola che ogni client deve rispettare. Validazione, parsing, checksum, similarity score, rimodellamento di JSON e inner loop di un calcolo numerico possono soddisfare questi test. Workflow, approvazioni, notifiche, autenticazione, sessioni utente, chiamate ad API esterne e policy di prodotto soggette a frequenti modifiche devono restare nell'applicazione. La necessità di tabelle di configurazione, feature flag o di un altro sistema è un segnale di avvertimento che una routine ha oltrepassato quel confine.
Esistono anche controlli operativi. Gli sviluppatori possono presentare la funzione insieme al codice SQL che la richiama, mentre i database administrator ne esaminano il filtro e il numero previsto di invocazioni. Oltre al privilegio per la creazione di routine, è richiesto il privilegio per la creazione di routine JavaScript, consentendo di concedere esplicitamente l'autorizzazione a scrivere routine JavaScript. Le definizioni delle routine dovrebbero essere conservate nel version control accanto alle schema migration, e le funzioni deterministic prive di stato nascosto possono essere testate con normali metodi di unit testing.