SQLite in Produzione: il Database "Piccolo" come Arma Segreta
Quando abbiamo progettato RAG Enterprise PRO per installazioni on-premise, ci serviva un database che non richiedesse un DBA, non avesse dipendenze esterne e funzionasse su qualsiasi macchina. SQLite si è rivelato la scelta perfetta per configurazioni, sessioni e metadati locali — e i numeri ci danno ragione.
Zero Configurazione, Zero Problemi: SQLite nel Mondo On-Premise
Il nostro prodotto RAG Enterprise PRO viene installato direttamente sui server dei clienti — studi legali, aziende sanitarie, enti pubblici. Ogni ambiente è diverso: c'è chi ha un server Linux minimale senza nemmeno Docker, chi ha Windows Server 2016 con policy IT rigidissime, chi ha macchine air-gapped senza accesso a Internet. In questo contesto, installare PostgreSQL o MySQL significherebbe aggiungere un layer di complessità enorme: porte da aprire, utenti da creare, backup da configurare, aggiornamenti di sicurezza da gestire. SQLite elimina tutto questo. È un singolo file .db che vive nella directory dell'applicazione. Non c'è un processo separato da avviare, non ci sono credenziali da gestire, non c'è nulla che possa "andare giù" indipendentemente dall'applicazione. Per RAG Enterprise PRO, usiamo SQLite per tre scopi principali: storage delle configurazioni utente (modelli LLM selezionati, parametri di chunking, soglie di similarità), gestione delle sessioni di chat (storico conversazioni, contesto accumulato), e metadati dei documenti indicizzati (nome file, data upload, stato di processing). Nessuno di questi use case richiede accesso concorrente pesante o transazioni distribuite — sono tutti pattern di lettura/scrittura sequenziale dove SQLite eccelle.
SQLite vs PostgreSQL: Quando Scegliere Cosa
Non siamo integralisti: nel nostro stack usiamo sia SQLite che PostgreSQL, ciascuno dove ha senso. La regola che seguiamo internamente è semplice. SQLite per: dati locali di una singola istanza applicativa, configurazioni, cache locale, prototipi rapidi, e qualsiasi scenario dove il deployment semplice è prioritario. PostgreSQL per: dati condivisi tra più servizi, CRM81 (il nostro CRM cloud-based dove più utenti accedono contemporaneamente), analytics con query complesse, e tutto ciò che richiede replicazione o alta disponibilità. Un esempio concreto: CRM81 usa PostgreSQL perché gestisce centinaia di utenti concorrenti che leggono e scrivono sulle stesse tabelle di contatti, deal e attività. Se usassimo SQLite, il WAL mode ci darebbe un singolo writer alla volta — inaccettabile per un CRM multi-utente. RAG Enterprise PRO, invece, è un'applicazione single-tenant dove ogni installazione serve un'organizzazione alla volta. Qui SQLite non solo basta, ma è superiore: deployment in 30 secondi, backup con una semplice copia del file, zero manutenzione. Un dato che ci ha sorpreso: nei nostri benchmark interni, SQLite in WAL mode è più veloce di PostgreSQL per le query di lettura semplici (lookup per chiave primaria) — circa 3x più veloce, perché non c'è overhead di rete né di protocollo client-server. Per le query analitiche complesse con JOIN su milioni di righe, ovviamente PostgreSQL vince.
Lezioni Apprese: SQLite in Produzione Senza Rimpianti
Dopo oltre un anno di SQLite in produzione su decine di installazioni RAG Enterprise PRO, ecco le lezioni che abbiamo imparato. Prima: abilita sempre WAL mode. Senza WAL, una scrittura blocca tutte le letture. Con WAL, le letture non vengono mai bloccate. Una riga di codice (PRAGMA journal_mode=WAL) che cambia tutto. Seconda lezione: gestisci le migrazioni con attenzione. Non avendo un tool di migrazione integrato come Alembic per PostgreSQL, abbiamo scritto un semplice sistema di versioning dello schema. Ogni aggiornamento di RAG Enterprise PRO controlla la versione dello schema nel database e applica le migrazioni necessarie in ordine. Funziona perfettamente e sono meno di 100 righe di Python. Terza: i backup sono banali ma non dimenticarli. Il nostro installer configura un cron job che copia il file .db ogni 6 ore. È tutto. Niente pg_dump, niente configurazioni complesse. Se qualcosa va storto, ripristini copiando un file. Quarta: non sottovalutare i limiti. SQLite non supporta ALTER TABLE DROP COLUMN nelle versioni più vecchie, non ha un tipo BOOLEAN nativo (usa 0/1), e le date sono stringhe. Sono limiti gestibili, ma bisogna conoscerli. Nel nostro codebase abbiamo un layer di astrazione sottile che normalizza questi comportamenti.
Servizi Correlati
Scopri come applichiamo queste tecnologie nei nostri progetti enterprise.
Interessato?
Contattaci per ricevere un preventivo personalizzato.
Securvita S.r.l. — i3k.eu