Quando usare SQLite: casi d'uso, limiti e quando evitarlo

La domanda di fondo

SQLite non è una versione più piccola di Postgres. È uno strumento di forma diversa. L'intero database è un file su disco, e la tua applicazione ci parla tramite una libreria collegata allo stesso processo: niente server, niente rete, niente utenti. Questo design rende SQLite eccellente per alcuni lavori e poco adatto per altri.

La domanda decisiva non è quasi mai "SQLite è abbastanza veloce?" (di solito lo è). È "la forma della mia applicazione corrisponde a ciò in cui SQLite è bravo?". A deciderlo sono soprattutto due cose: dove vivono i dati e quante cose ci scrivono contemporaneamente.

Usa SQLite quando i dati vivono con l'app

SQLite dà il meglio quando il database appartiene a un'applicazione su una sola macchina. Il file sta accanto al tuo codice, l'app lo apre direttamente, e questa è tutta l'architettura.

-- Uno schema tipico in cui "i dati vivono con l'app":
-- l'archivio locale di un'app desktop per prendere appunti.
CREATE TABLE notes (
    id        INTEGER PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT,
    created   TEXT DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO notes (title, body) VALUES
    ('Groceries', 'milk, bread, coffee'),
    ('Ideas',     'sqlite tutorial outline');

SELECT id, title, created FROM notes;

Quel piccolo schema potrebbe essere l'intero backend di un'app reale. Alcuni casi in cui questo schema si adatta in modo naturale:

• App desktop e mobile. Ogni app iOS e Android che ha bisogno di archiviazione locale strutturata usa SQLite sotto il cofano. Lo stesso vale per Firefox, Chrome e la maggior parte dei browser.
• Strumenti da riga di comando. git, i gestori di pacchetti e i gestori di dotfile usano tutti database embedded.
• Dispositivi embedded. Router, auto, aerei: qualsiasi cosa abbia bisogno di un database in poche centinaia di kilobyte.
• Suite di test. Un file SQLite nuovo (o un database :memory:) per ogni test è più veloce e più isolato che avviare Postgres.

Se i tuoi dati non devono essere condivisi tra più macchine, SQLite è probabilmente la risposta giusta.

Usa SQLite per siti web con tante letture

SQLite gestisce le letture benissimo. Molti lettori concorrenti, nessuna contesa, tempi di query nell'ordine dei microsecondi per le ricerche su indice. Se il tuo sito è fatto soprattutto di persone che leggono contenuti (blog, documentazione, siti di marketing, piccole dashboard SaaS), SQLite regge bene, spesso meglio di un Postgres collegato in rete perché non c'è il viaggio di andata e ritorno.

-- La tabella dei post di un blog.
CREATE TABLE posts (
    slug      TEXT PRIMARY KEY,
    title     TEXT NOT NULL,
    body      TEXT NOT NULL,
    published TEXT
);

CREATE INDEX idx_posts_published ON posts(published DESC);

INSERT INTO posts VALUES
    ('hello-world', 'Hello, World', 'First post.', '2024-01-01'),
    ('sqlite-rocks', 'Why SQLite',  'Single-file DB.', '2024-02-15');

SELECT slug, title FROM posts ORDER BY published DESC LIMIT 10;

Il tranello sono le scritture. SQLite serializza le scritture: solo uno scrittore alla volta può avere il lock. Per un blog con pochi autori non te ne accorgi nemmeno. Per un'app di chat con migliaia di utenti che mandano messaggi ogni secondo, è un problema.

La modalità WAL (write-ahead logging, la vediamo più avanti) alza parecchio il tetto, permettendo ai lettori e allo scrittore di lavorare in parallelo. Molti siti in produzione servono milioni di richieste al giorno con SQLite + WAL.

Usa SQLite per cache locali e dati temporanei

Ogni volta che ti serve un'archiviazione locale strutturata, qualcosa di più di un file JSON ma di meno di un database server completo, SQLite è difficile da battere.

-- Una tabella di cache per un client HTTP.
CREATE TABLE http_cache (
    url        TEXT PRIMARY KEY,
    body       BLOB NOT NULL,
    expires_at INTEGER NOT NULL
);

INSERT INTO http_cache (url, body, expires_at)
    VALUES ('https://api.example.com/users/1', x'7b2269...', 1735689600);

DELETE FROM http_cache WHERE expires_at < strftime('%s', 'now');
SELECT count(*) FROM http_cache;

Log, buffer di analytics, staging per ETL, feature store di machine learning, indici degli IDE: tutti ambienti naturali per SQLite. Il file è portabile, il linguaggio di query è SQL completo e non c'è nessun server da sorvegliare.

Non usare SQLite con molti scrittori concorrenti

Questo è il limite che coglie di sorpresa. SQLite usa un lock di scrittura a livello di database: uno scrittore, punto. Due processi che provano a inserire nello stesso istante significano che uno dei due aspetta.

Per la maggior parte delle app non importa: le scritture sono rare e rapide. Ma se il tuo carico di lavoro assomiglia a:

• un SaaS multi tenant con migliaia di utenti che scrivono tutti contemporaneamente,
• una coda di messaggi o un log di eventi ad alto throughput,
• il backend di un gioco in tempo reale o di una chat con cambi di stato continui,

allora SQLite diventerà il collo di bottiglia. Postgres e MySQL usano lock a livello di riga e sono stati costruiti proprio per questo. Scegli loro.

-- L'errore che vedrai quando gli scrittori si accumulano:
Error: database is locked

Se vedi questo errore con un carico normale, SQLite è lo strumento sbagliato, non un bug da aggirare.

Non usare SQLite su più macchine

SQLite è una libreria che gira nel processo. L'applicazione legge e scrive direttamente il file, il che significa che il file deve stare su un disco su cui l'applicazione può fare read() e write() con le normali chiamate al file system.

Questo esclude:

• Più server applicativi dietro un load balancer che vogliono condividere un solo database. (I file system di rete come NFS tecnicamente funzionano, ma sotto carico corrompono il file. Non farlo.)
• Funzioni serverless in cui ogni invocazione gira su una macchina diversa.
• Pod Kubernetes che hanno bisogno di un database condiviso, a meno che tu non usi un deployment con un solo pod e un volume persistente.

Se la tua architettura ha più di un processo su più di una macchina che scrive nel database, ti serve un database client server. Il confine è questo.

Non usare SQLite quando ti servono utenti a livello di database

SQLite non ha il concetto di utenti, ruoli o permessi. Il database è un file: chi può leggere il file può leggere tutto; chi può scriverlo può scrivere tutto. Il controllo degli accessi è compito del sistema operativo.

Per un'app desktop con un solo utente va bene. Per un sistema multi tenant in cui persone diverse hanno bisogno di privilegi diversi dentro il database, ti servono Postgres o MySQL.

Una checklist rapida per decidere

Scorri questo elenco. Se rispondi "sì" a tutte le voci, SQLite è probabilmente un'ottima scelta:

• Il database sta sulla stessa macchina dell'applicazione.
• Ci parla un solo processo (o pochi, che per lo più leggono).
• I dati totali stanno comodamente su un disco: i terabyte vanno bene, ma resta un solo disco.
• Non ti servono permessi utente a livello di database.
• Le scritture concorrenti sono occasionali, non il carico di lavoro principale.

Se anche una sola risposta è "no", guarda invece Postgres o MySQL. Le prossime due pagine li confrontano direttamente.

Cosa portarti a casa

• SQLite è la scelta giusta quando il database è locale rispetto all'applicazione: desktop, mobile, embedded, strumenti da riga di comando, suite di test, siti con tante letture, cache locali.
• È di livello produzione: miliardi di dispositivi lo includono. I vincoli sono architetturali, non di qualità.
• Evitalo quando ti servono molti scrittori concorrenti, accesso da più macchine o permessi di database per utente.

Prossimo passo: installare SQLite

Basta teoria. La prossima pagina spiega come avere SQLite sul tuo computer (su macOS e sulla maggior parte delle distribuzioni Linux c'è già, su Windows basta un download) e come verificare l'installazione dalla riga di comando.