Quando si parte con un prodotto indie, la discussione su SQLite o Postgres scivola quasi sempre sulla scala: “SQLite non regge”, “Postgres è overkill”. Per la maggior parte dei progetti piccoli entrambe le frasi sono sbagliate. La scala, all'inizio, non è il vincolo. Lo sono il modo in cui deployi, come fai i backup, quanti processi scrivono insieme e dove vive il tuo codice.
In breve: Per un prodotto indie la scelta tra SQLite e Postgres raramente dipende dal traffico. SQLite basta se hai un solo processo che scrive, un disco persistente e un backup che hai già provato con un restore vero. Postgres diventa la strada più semplice quando il deploy è distribuito o stateless, quando più servizi condividono gli stessi dati o quando ti servono estensioni come pgvector o PostGIS.
Dove SQLite è davvero sufficiente
SQLite è un file. Nessun server da tenere acceso, nessuna connessione di rete, nessuna password da ruotare. Con la modalità WAL attiva gestisce bene molte letture concorrenti e un flusso di scritture moderato, che per un SaaS con qualche centinaio di utenti attivi è spesso più che sufficiente. Le query sono veloci proprio perché non attraversano la rete.
Funziona molto bene quando hai un singolo processo applicativo su una macchina o un volume persistente: una VPS, un container con disco montato, un'app desktop o un tool interno. Il deploy è il tuo binario più un file, e i test girano su un database vero creato in millisecondi.
I vincoli che contano più della scala
Il primo è l'hosting. Molte piattaforme serverless o con container effimeri non garantiscono un disco persistente condiviso tra istanze. Se la tua app gira su più repliche che si accendono e si spengono, un file SQLite locale non è la scelta naturale, a meno di usare un servizio che replica SQLite per te. Se devi ancora scegliere dove ospitare l'app, il confronto Vercel vs Cloudflare vs VPS parte proprio da qui: cosa ti porti via, e cosa devi riscrivere, se un giorno cambi piattaforma.
Il secondo sono i backup. Copiare il file mentre l'app scrive può darti una copia incoerente: servono il comando di backup di SQLite, VACUUM INTO o uno strumento di replica continua verso object storage. Non è difficile, ma va fatto e va provato con un restore vero, non solo pianificato.
Il terzo è la concorrenza in scrittura. SQLite serializza le scritture: con transazioni brevi va bene, con job lunghi che tengono il lock mentre le richieste web aspettano iniziano i timeout. Se prevedi worker in background che scrivono molto in parallelo all'app, è un segnale da prendere sul serio.
Quando Postgres costa meno complessità, non di più
Postgres ha un costo iniziale reale: un servizio in più, connessioni da gestire, un pooler se usi funzioni serverless, migrazioni da pensare con un po' più di attenzione. Oggi però un Postgres gestito si attiva in pochi minuti e include backup automatici e point-in-time recovery, cioè proprio la parte che con SQLite devi costruirti.
Diventa la scelta più semplice quando hai più servizi che leggono e scrivono lo stesso dato, quando ti servono ricerca full-text seria, JSONB indicizzato, estensioni come pgvector o PostGIS, oppure quando il tuo hosting è stateless per natura. In quei casi forzare SQLite significa reinventare pezzi che Postgres ti dà già pronti.
Una regola pratica
Scegli SQLite se oggi hai un solo processo che scrive, un disco persistente e un piano di backup che hai già provato. Scegli Postgres se il deploy è distribuito, se più componenti condividono i dati o se le funzionalità che ti servono esistono già come estensioni. In entrambi i casi scrivi SQL il più possibile standard e tieni l'accesso ai dati dietro un livello sottile: migrare dopo sarà un lavoro di qualche giorno, non una riscrittura. La domanda giusta non è quanto crescerai, ma quanta infrastruttura vuoi gestire mentre cresci. Se ti serve SQLite ma il file non può restare su un solo disco, il seguito è Turso, D1 o Postgres gestito: repliche, backup, latenza e lock-in a confronto.
Se lavori su Cloudflare, D1 sposta parte di questi vincoli: è SQLite gestito accanto ai Worker, e ne ho parlato in Workers, D1 e R2. La stessa logica, partire dal vincolo e non dalla moda, vale per il CMS: Strapi vs EmDash vs WordPress.
