{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreifbqrhhoochromtpnvl6ljn773bwqivp7ltimavnwlmyinyu6lk6u",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mopkve2hdw62"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreihb5dogt6yuz6c2hoor7pqk5d4qvvgbcwssmrzz6z5qthafbayq3u"
    },
    "mimeType": "image/webp",
    "size": 89618
  },
  "path": "/frontendfacile/sqlite-riscritta-in-rust-perche-qualcuno-sta-provando-a-toccare-il-codice-piu-affidabile-che-505g",
  "publishedAt": "2026-06-20T09:08:34.000Z",
  "site": "https://dev.to",
  "tags": [
    "sqlite",
    "rust",
    "databaseembedded",
    "concorrenza",
    "https://frontendfacile.it/blog/sqlite-riscritta-in-rust-perche-qualcuno-sta-provando-a-toccare-il-codice-piu-af"
  ],
  "textContent": "> 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.\n\nNel 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.\n\nQuesta è 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.\n\nOra 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.\n\n##  Perché toccare SQLite, se funziona così bene?\n\nSQLite non è “il problema”. Anzi: è considerata estremamente robusta perché è conservativa, minimalista, e custodita con un rigore quasi maniacale.\n\nIl 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.\n\nQuesta 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.\n\nDa qui nasce l’idea: costruire un’alternativa che mantenga la compatibilità con SQLite, ma che possa evolvere con un set di priorità diverse.\n\n##  Cosa significa davvero “drop‑in replacement”\n\nQuando parliamo di database embedded, _la fiducia_ è tutto. Non basta essere veloci. Non basta avere feature nuove. Il requisito numero uno è: **non perdere mai dati**.\n\nIl requisito numero due è: **non costringere gli utenti a riscrivere l’app**.\n\nEssere un drop‑in replacement significa:\n\n  * compatibilità con il formato e/o comportamento atteso (SQL, pragma, edge case noti);\n  * stesse semantiche nei casi limite che la gente dà per scontati da anni;\n  * integrazione semplice nei binding e nei driver esistenti.\n\n\n\nIn 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.\n\n##  Le tre aree dove una riscrittura può cambiare le regole\n\nAlcune 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.\n\n###  1) Concorrenza in scrittura: non solo “un writer alla volta”\n\nUn 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.\n\nUn 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:\n\n  * molte richieste concorrenti;\n  * job asincroni in background;\n  * app locali con più thread/worker.\n\n\n\nPer un frontend, l’impatto è indiretto ma concreto: API più reattive sotto carico, meno code lato server, meno timeout percepiti in UI.\n\n###  2) I/O asincrono: evitare di bloccare thread quando si tocca il disco\n\nSQLite tipicamente esegue I/O su disco in modo bloccante: quando legge o scrive, il thread aspetta.\n\nIn architetture moderne (specialmente in ambienti con runtime async), la possibilità di **cedere il controllo durante l’I/O** aiuta a:\n\n  * aumentare la capacità di gestire richieste concorrenti;\n  * ridurre sprechi di thread in attesa;\n  * migliorare la prevedibilità della latenza.\n\n\n\nPer chi lavora con Node.js, Rust, o servizi con event loop, questa differenza non è un dettaglio: è una leva architetturale.\n\n###  3) Vector search: embeddings nello stesso database\n\nLa svolta “AI‑driven” ha creato un nuovo requisito: **salvare embeddings e cercare i più vicini rapidamente**.\n\nLa soluzione comune oggi è aggiungere un secondo sistema (vector database o servizio esterno). Funziona, ma raddoppia la complessità:\n\n  * due database, due backup strategy;\n  * due permessi/connessioni;\n  * sincronizzazione applicativa;\n  * query che diventano una pipeline di chiamate.\n\n\n\nIntegrare tipi vettoriali e indici nativi significa poter tenere:\n\n  * dati relazionali tradizionali;\n  * embeddings;\n  * e query di similarità\n\n\n\n…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.\n\n##  Il vero problema: guadagnarsi la fiducia (senza 25 anni di storia)\n\nAggiungere feature è relativamente “facile”. Il difficile è costruire un database che non tradisca mai.\n\nQui entra in gioco un’idea molto interessante: **test tramite simulazione deterministica**.\n\nInvece 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** :\n\n  * perdita di alimentazione durante una scrittura;\n  * pagina corrotta a metà;\n  * disco che “mente” e conferma un flush che non è avvenuto;\n  * interruzioni nel momento peggiore.\n\n\n\nLa 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.\n\n##  Implicazioni pratiche per chi fa frontend (e prodotto)\n\nAnche se “riscrivere un database” sembra lontano dalla UI, le conseguenze arrivano fino al client:\n\n  * **Meno dipendenze di sistema** : un motore embedded con capacità moderne può ridurre il numero di servizi esterni necessari.\n  * **Offline e edge più potenti** : avere SQL + vector search in locale abilita ricerche semantiche e feature AI senza roundtrip costanti.\n  * **Prestazioni percepite** : concorrenza e I/O non bloccante migliorano latenza e throughput dei servizi che alimentano l’interfaccia.\n\n\n\n##  Sintesi: una scommessa rischiosa, ma comprensibile\n\nSQLite è diventata “invisibile” perché è affidabile e semplice. Riscriverla è rischioso proprio perché la posta in gioco è massima: i dati.\n\nEppure, 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.\n\nLa 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.\n\nArticolo originale: https://frontendfacile.it/blog/sqlite-riscritta-in-rust-perche-qualcuno-sta-provando-a-toccare-il-codice-piu-af",
  "title": "SQLite riscritta in Rust? Perché qualcuno sta provando a toccare il codice “più affidabile” che abbiamo"
}