PostgreSQL o MySQL? Perché per i gestionali grandi scelgo Supabase con Nuxt

Ultimamente lavoro molto con Nuxt, come ho già raccontato in React o Vue: perché scelgo Nuxt, e sempre più spesso su progetti complessi: gestionali, aree riservate, piattaforme con molti dati. Su questi progetti non uso Nuxt Content, Netlify Blobs o un servizio esterno per salvare i dati. Uso un database vero, con le sue regole, e negli ultimi lavori è PostgreSQL, quasi sempre tramite Supabase. Ne sono rimasto piacevolmente stupito, e qui spiego perché.

Perché Nuxt Content e Blobs non bastano

Nuxt Content è ottimo per i contenuti editoriali, cioè testi e pagine che cambiano di rado e si versionano come file. Netlify Blobs è un archivio comodo per file e dati semplici. Nessuno dei due sa che un cliente ha tanti ordini, che un ordine non può esistere senza cliente, o che ogni utente deve vedere solo i propri dati. Un gestionale ha bisogno di tutto questo, e rifarlo nel codice significa costruirsi male un database. Meglio partire da uno che lo fa già.

PostgreSQL e MySQL: in cosa sono diversi

Sono entrambi database «a tabelle», con righe e colonne. MySQL è solido e per un sito con tabelle semplici è una scelta più che valida. PostgreSQL ha più strumenti quando i dati sono tanti e collegati tra loro. Quelli che mi servono davvero sono quattro.

Dati più ricchi e regole più rigide

PostgreSQL permette di salvare in una colonna anche dati flessibili (il formato jsonb, utile per le opzioni di un contratto o per i dati che arrivano da un altro servizio) e di interrogarli senza fatica. Con gli enum, cioè un elenco di valori ammessi, lo stato di un ordine può essere solo «in lavorazione», «spedito» o «consegnato»: lo garantisce il database, non il codice. Un dettaglio da sapere: aggiungere un valore all'elenco è facile, toglierne uno no.

Modifiche sicure alla struttura

Quando il progetto cresce, la struttura delle tabelle cambia di continuo. In PostgreSQL una modifica che riguarda più tabelle o riesce per intero, o non cambia niente. In MySQL se qualcosa va storto a metà, il database può restare a metà strada e va sistemato a mano.

Veloce anche con tanti dati

PostgreSQL permette di creare indici (le scorciatoie che rendono veloci le ricerche) solo sulle righe che interessano, per esempio gli ordini ancora aperti, ignorando quelli archiviati. Così le tabelle grandi restano rapide. Ha anche la ricerca nei testi e la ricerca per somiglianza già integrate.

Sicurezza riga per riga

È la differenza che pesa di più in un gestionale. Si chiama Row Level Security (RLS): le regole su chi può vedere cosa stanno nel database. Un cliente vede solo i propri ordini, anche se in un punto del codice mi dimentico un filtro. MySQL non ha nulla di equivalente, e le regole restano sparse nell'applicazione.

E quando MySQL va ancora bene

Se il progetto è un sito con poche tabelle, magari su un hosting che offre già MySQL e un pannello come WordPress, non c'è motivo di cambiare: il vantaggio di PostgreSQL si vede quando i dati diventano tanti, collegati e riservati a utenti diversi. Per me la soglia è il gestionale, non il sito vetrina.

Cosa aggiunge Supabase

Supabase non sostituisce PostgreSQL: gli costruisce attorno ciò che altrimenti dovrei fare e mantenere io. Uso:

• l'autenticazione, collegata direttamente alle regole di sicurezza per riga;
• lo storage, per i file, con gli stessi permessi;
• i webhook, avvisi automatici che chiamano un altro servizio quando una riga cambia;
• tabelle, enum e viste, queste ultime come «tabelle virtuali» costruite da una query, comode per i report.

Due attenzioni. Le viste di base ignorano le regole per riga, quindi vanno configurate perché le rispettino. E in ambiente serverless, come quello di Netlify, PostgreSQL gestisce male molte connessioni aperte insieme: serve un intermediario (il pooler) che le smista, e Supabase ne ha uno.

Le note negative: costi e self-hosting

Oggi uso Supabase nel cloud gestito, e qui c'è la nota negativa: i costi crescono con la potenza del database, lo spazio e il traffico, e per un gestionale con molti dati possono diventare una voce importante. Per questo voglio provare il self-hosting, cioè installarlo su un mio server. Non l'ho ancora fatto, quindi quello che segue viene dalla documentazione, non dall'esperienza.

Self-hosted, Supabase non è un solo programma ma un insieme di servizi che girano insieme. Le difficoltà che mi aspetto:

• Aggiornamenti: ogni servizio esce con i suoi tempi e vanno aggiornati senza rompere nulla.
• Backup: il ripristino a un momento preciso non è incluso e va costruito con altri strumenti.
• Sicurezza: chiavi, certificati, firewall e invio delle email di accesso sono a mio carico.
• Controllo continuo: monitoraggio e protezione dai guasti, che nel cloud sono già compresi.

Il risparmio sul canone si paga in tempo di gestione, e per un cliente che non ha chi segua un server il cloud può restare la scelta migliore.

Come la vedo io

Mi piace Supabase perché sotto c'è PostgreSQL puro: la struttura dei dati è mia, scritta in file versionati su Git come il resto del codice, e se un giorno volessi lasciare la piattaforma porterei con me il database. Il resto del metodo non cambia: Nuxt e TypeScript, ogni modifica con la sua anteprima su Netlify, il ramo principale mai toccato direttamente. Ultimamente miglioro di continuo il mio modo di costruire questi sistemi, e gli ultimi siti nascono già su questa base.

Perché affidarlo a me

Dal 1999 ho consegnato più di 300 progetti e collaboro con più di 30 agenzie. Se hai un gestionale che sta stretto in fogli di calcolo o in un database cresciuto male, scrivimi: in una chiacchierata di circa 20 minuti capiamo se ha senso ripartire da una base solida. Il servizio è Software su misura e ne parlo anche in Gestionale su misura o Excel.