SQLite vs Postgres su un progetto piccolo

Per un progetto piccolo con un solo processo applicativo, SQLite in modalità WAL basta: 300.000 righe occupano 26,8 MB e le letture indicizzate restano sotto un decimo di millisecondo. PostgreSQL conviene quando servono scrittori concorrenti, client in rete o estensioni che SQLite non ha.

Cosa ottieni

• Un file: il database è un file sul disco dell'applicazione, senza servizio, porta o credenziale da configurare.
• Backup in una riga: il comando .backup legge uno stato consistente anche con il sito in funzione.
• Transazioni ACID: le garanzie su atomicità e isolamento ci sono, con BEGIN IMMEDIATE per prendere il lock di scrittura subito.
• Una licenza che non chiede nulla: pubblico dominio, nessun obbligo di attribuzione o di apertura del codice.

Cosa perdi

• Scrittori concorrenti: uno solo alla volta scrive; gli altri aspettano il lock, e senza busy_timeout ricevono un errore invece di attendere.
• Più host: il file sta su un disco locale. Su un filesystem di rete il locking non è affidabile, quindi due server non condividono lo stesso database.
• Estensioni e repliche: niente PostGIS, nessuna replica in lettura nativa, nessun parallel query.
• Ruoli e permessi: i permessi sono quelli del filesystem, non dell'utente del database.

I numeri del test

Quando conviene migrare

Il segnale non è la dimensione del database, è il numero di processi che scrivono. Due istanze dell'applicazione dietro un load balancer violano già il modello a scrittore singolo, e un jobs worker che scrive mentre il sito scrive crea attese che nessun indice risolve. Aggiungi a questo la richiesta di repliche in lettura, di backup point-in-time o di un'estensione geografica e la migrazione si paga da sola.

Modalità, backup, attese

Tre impostazioni fanno la differenza in produzione: WAL per non bloccare le letture durante una scrittura, un busy_timeout perché le attese diventino attese invece di errori, e il backup con .backup invece della copia del file. Le stesse impostazioni rendono il passaggio a PostgreSQL più semplice, perché la logica applicativa non dipende dal motore.

sqlite3 app.db "PRAGMA journal_mode=WAL; PRAGMA busy_timeout=5000;"
sqlite3 app.db ".backup 'backup.db'"
sqlite3 app.db "PRAGMA integrity_check;"

Il backup online lascia intatti i file -wal e -shm del database in uso: sono parte dello stato, non rifiuti. Se copi il database a mano mentre l'applicazione scrive, il rischio è un file che apre senza errori ma con pagine incoerenti, e il controllo di integrità è l'unico modo per accorgersene.

Il catalogo EneUI

Una vista sulle righe serve comunque, qualunque sia il motore: in catalogo ci sono i componenti tabella, i blocchi dashboard e il record table di Origin UI, licenza MIT dichiarata a monte. Controllo eseguito il 1 novembre 2026 sul catalogo da 111.985 componenti.

La limitazione

I numeri vengono da una macchina sola, con Node e un disco locale di cui non conosciamo le prestazioni: non sono un confronto fra motori. Non abbiamo misurato il comportamento con più scrittori simultanei né la latenza su un filesystem di rete, che è proprio il caso in cui SQLite peggiora. Se il deploy è serverless, multi-regione o su più container che scrivono, la risposta è PostgreSQL e non c'è misura che la cambi.

Dove continuare

La forma delle query e del contratto è in progettare un'API; le regole di cache che decidono metà della latenza percepita sono in header di cache HTTP. Se stai scegliendo fra stili di API, il confronto con i costi di entrambi è in MCP e REST.