Per un SaaS destinato a scalare, la scelta di default corretta è PostgreSQL. Copre circa il 90% di ciò che serve a un prodotto web o mobile: dati transazionali, relazioni tra entità, ricerca, JSON, code leggere e persino parte del carico vettoriale per l’IA. La vera domanda non è quasi mai "relazionale o NoSQL": è "ho una ragione precisa per NON usare Postgres". Nella maggior parte dei casi, no.
PostgreSQL di default: perché funziona 9 volte su 10
Un SaaS gestisce dati strutturati e collegati tra loro: utenti che appartengono a organizzazioni, abbonamenti legati a fatture, progetti legati a task. È esattamente ciò per cui i database relazionali sono fatti. Postgres aggiunge a questa base dei superpoteri che evitano di impilare strumenti: colonne JSONB per il semi-strutturato, ricerca full-text integrata, l’estensione pgvector per gli embedding dell’IA e vincoli che garantiscono l’integrità dei tuoi dati.
- Transazioni ACID: pagamenti e dati critici restano coerenti, anche dopo un crash.
- Un solo sistema da gestire, salvare e monitorare invece di tre: meno costi, meno guasti.
- Ecosistema maturo: Prisma, migrazioni, replica, hosting gestito ovunque (Cloud Run, Neon, Supabase, RDS).
- JSONB quando serve flessibilità, senza rinunciare al relazionale per il resto.
Relazionale vs NoSQL: quando uscire da Postgres
Il NoSQL (MongoDB, DynamoDB, Firestore) non è "più moderno", risponde ad altri vincoli. Conviene solo se il tuo caso d’uso calza davvero: volumi enormi con scrittura molto intensa, uno schema realmente imprevedibile o la necessità di una distribuzione geografica estrema. Per un tipico SaaS B2B in fase di lancio e crescita, quei vincoli non esistono ancora, e adottare il NoSQL troppo presto ti fa pagare in complessità qualcosa che non userai mai.
Scegliere NoSQL perché "scala" quando hai 200 utenti significa ottimizzare un problema che non hai, a scapito di quelli che hai già.
Indici, migrazioni, scaling: tre riflessi da avere dalla V1
Un database ben scelto non basta: sono tre abitudini a decidere se il tuo SaaS regge a 10.000 utenti. Primo, gli indici: una query che scansiona un’intera tabella è veloce a 100 righe e catastrofica a 1 milione. Indicizza le colonne che filtri e unisci di frequente, e misura con EXPLAIN. Poi le migrazioni: ogni cambiamento di schema deve essere versionato e ripetibile (Prisma Migrate), mai applicato a mano in produzione. Infine lo scaling: prima verticale (più CPU/RAM), poi repliche in lettura, e allo sharding si pensa solo molto tardi: la maggior parte dei SaaS non ci arriva mai.
- Indici: punta alle colonne delle clausole WHERE, JOIN e ORDER BY; un indice sbagliato costa in scrittura, uno mancante uccide la lettura.
- Migrazioni: versionate, testate, reversibili: il database evolve col prodotto senza downtime.
- Scaling: prima verticale, poi repliche in lettura; Postgres regge milioni di righe molto prima che si parli di sharding.
La scelta giusta per una V1
Scegliere PostgreSQL dal primo giorno, modellare in modo pulito, mettere gli indici giusti e versionare le migrazioni: è questo che ti evita una riscrittura al dodicesimo mese. È esattamente la base che mettiamo in piedi nelle nostre V1 consegnate in 7 giorni a 15.000 € — Next.js, NestJS, Prisma e Postgres —, un database che ti accompagna dal primo cliente fino al salto di scala, senza debito tecnico nascosto.