Dalla libreria embedded che ha invaso ogni dispositivo a un’implementazione moderna con concorrenza, async I/O e vector search: cosa cambia davvero per chi sviluppa app.
Nel frontend e nel full‑stack capita spesso di parlare di database come servizi: Postgres gestito, cluster, repliche, connessioni, pooling, credenziali e una lunga lista di “cose che possono rompersi”. Ma esiste un’altra filosofia, più vicina all’idea di “dipendenza” che di “infrastruttura”: un motore SQL che vive dentro l’applicazione.
Questa è la ragione per cui SQLite è ovunque. È una libreria, non un server. Legge e scrive su un singolo file su disco. Riduce drasticamente configurazione, porte, processi separati e complessità operativa. Ed è proprio questa semplicità a renderla una delle fondamenta silenziose dell’informatica moderna: la usi in browser, smartphone, desktop app, tool CLI, IoT… spesso senza nemmeno accorgertene.
Ora immagina di riscrivere tutto da capo, in Rust, cercando di essere compatibile al 100% e allo stesso tempo più “moderna”. Sembra un’idea folle per definizione—finché non inizi a guardare ai limiti pratici che oggi emergono in molte applicazioni.
SQLite non è “il problema”. Anzi: è considerata estremamente robusta perché è conservativa, minimalista, e custodita con un rigore quasi maniacale.
Il punto è un altro: il suo modello di sviluppo e manutenzione è atipico rispetto a quello che molti intendono per open source collaborativo. Il codice è disponibile e utilizzabile liberamente, ma l’evoluzione è guidata da pochissime persone e—di fatto—non segue la dinamica classica delle contribution esterne.
Questa scelta ha un effetto collaterale positivo: riduce il rischio di regressioni introdotte da cambiamenti non coerenti con la visione del progetto. Ma ha anche un costo: se la tua azienda o il tuo prodotto hanno esigenze nuove (concorrenza più spinta, I/O non bloccante, funzionalità specifiche), “aspettare che arrivi upstream” non è sempre un’opzione.
Da qui nasce l’idea: costruire un’alternativa che mantenga la compatibilità con SQLite, ma che possa evolvere con un set di priorità diverse.
Quando parliamo di database embedded, la fiducia è tutto. Non basta essere veloci. Non basta avere feature nuove. Il requisito numero uno è: non perdere mai dati.
Il requisito numero due è: non costringere gli utenti a riscrivere l’app.
Essere un drop‑in replacement significa:
In pratica: “lo sostituisco e funziona” deve valere non solo per l’happy path, ma anche per i percorsi più brutti—quelli che incontrerai in produzione alle 3 di notte.
Alcune scelte architetturali di SQLite sono volutamente conservative. Funzionano benissimo in tantissimi scenari, ma diventano colli di bottiglia quando l’app cresce o quando cambiano le aspettative.
Un limite storico di SQLite è il modello in cui, semplificando, solo uno writer può scrivere alla volta sul database. È una scelta coerente con un file singolo e con l’obiettivo di robustezza.
Un approccio più moderno prova a consentire più scritture simultanee su porzioni diverse dei dati, facendo emergere il conflitto solo quando due operazioni toccano realmente le stesse righe (o la stessa area logica). Se funziona bene, questo cambia parecchio per carichi con:
Per un frontend, l’impatto è indiretto ma concreto: API più reattive sotto carico, meno code lato server, meno timeout percepiti in UI.
SQLite tipicamente esegue I/O su disco in modo bloccante: quando legge o scrive, il thread aspetta.
In architetture moderne (specialmente in ambienti con runtime async), la possibilità di cedere il controllo durante l’I/O aiuta a:
Per chi lavora con Node.js, Rust, o servizi con event loop, questa differenza non è un dettaglio: è una leva architetturale.
La svolta “AI‑driven” ha creato un nuovo requisito: salvare embeddings e cercare i più vicini rapidamente.
La soluzione comune oggi è aggiungere un secondo sistema (vector database o servizio esterno). Funziona, ma raddoppia la complessità:
Integrare tipi vettoriali e indici nativi significa poter tenere:
…in un unico file, con un unico linguaggio (SQL) e un unico modello operativo. Per prodotti piccoli/medi—o per edge/desktop/mobile—questa è una semplificazione enorme.
Aggiungere feature è relativamente “facile”. Il difficile è costruire un database che non tradisca mai.
Qui entra in gioco un’idea molto interessante: test tramite simulazione deterministica.
Invece di affidarsi solo a test tradizionali, si esegue il database in un ambiente simulato dove puoi controllare tempo e condizioni e, soprattutto, iniettare guasti riproducibili:
La parte cruciale è la ripetibilità: stesso seed, stesso scenario, stesso fallimento, fino a quando il bug viene isolato e rimosso. È un modo pragmatico per attaccare il tipo di problemi che non vuoi mai scoprire su un laptop dell’utente o in un POS in negozio.
Anche se “riscrivere un database” sembra lontano dalla UI, le conseguenze arrivano fino al client:
SQLite è diventata “invisibile” perché è affidabile e semplice. Riscriverla è rischioso proprio perché la posta in gioco è massima: i dati.
Eppure, in un mondo dove servono più concorrenza, integrazione async e funzionalità come la vector search senza moltiplicare i componenti, la spinta verso un’alternativa compatibile e più evolvibile è naturale.
La domanda non è tanto se sia una buona idea in assoluto, ma per quali prodotti e con quali garanzie. La differenza la farà la capacità di dimostrare affidabilità nel tempo, con test che cercano attivamente il fallimento—prima che lo faccia la produzione.
Articolo originale: https://frontendfacile.it/blog/sqlite-riscritta-in-rust-perche-qualcuno-sta-provando-a-toccare-il-codice-piu-af