Quando un’azienda mi chiede di costruire un software gestionale, un portale o una piattaforma, la prima domanda tecnica importante non riguarda il colore dei pulsanti: riguarda i dati. Scegliere il database per una web app è una di quelle decisioni che, se presa bene all’inizio, ti fa risparmiare mesi di lavoro in futuro. Se presa male, diventa il collo di bottiglia che rallenta tutto e costa caro da correggere. In questo articolo spiego come ragiono quando progetto la base dati di un’applicazione, con un linguaggio comprensibile anche a chi non scrive codice.
Perché il database è il cuore di una web app
Una web app, in fondo, è un programma che legge e scrive dati: utenti, ordini, documenti, prenotazioni, transazioni. Il database è il luogo dove queste informazioni vivono in modo permanente e sicuro. Tutto il resto — l’interfaccia, le notifiche, i report — gira attorno a questo nucleo.
Per questo la scelta del database per una web app non è un dettaglio tecnico secondario, ma una decisione architetturale. Determina quanto velocemente l’applicazione risponde, quanto facilmente cresce nel tempo, quanto è solido in caso di errore e quanto costa mantenerla. Quando costruisco un prodotto end-to-end, dalla prima riga di codice fino all’infrastruttura che lo ospita, parto sempre da qui.
SQL o NoSQL: la prima vera scelta
La distinzione più importante è tra database relazionali (SQL) e non relazionali (NoSQL). Non esiste il “migliore” in assoluto: esiste quello giusto per il problema che stai risolvendo.
I database relazionali come PostgreSQL e MySQL organizzano i dati in tabelle collegate tra loro, con regole rigorose. Sono la scelta ideale quando i dati hanno una struttura chiara e le relazioni contano: un gestionale con clienti, fatture e prodotti, un sistema di prenotazioni, un’area amministrativa. Garantiscono coerenza: o un’operazione va a buon fine completamente, o non viene registrata affatto. Per la maggior parte delle web app aziendali che sviluppo, questa è la base di partenza.
I database NoSQL come MongoDB o Redis, invece, rinunciano a parte di quella rigidità in cambio di flessibilità e velocità su certi scenari: grandi volumi di dati poco strutturati, cataloghi che cambiano forma di continuo, sistemi di cache, dati in tempo reale. Spesso convivono con un database relazionale, non lo sostituiscono.
- Scegli SQL quando i dati sono strutturati, le relazioni sono importanti e ti serve coerenza assoluta (gestionali, e-commerce, contabilità).
- Scegli NoSQL quando hai bisogno di massima flessibilità sullo schema, enorme scalabilità orizzontale o velocità su dati semplici (log, sessioni, cache).
- Usa entrambi quando ha senso: PostgreSQL per i dati di business, Redis per la cache e le code di lavoro.
Perché scelgo spesso PostgreSQL
Quando devo decidere il database per una web app su misura, la mia scelta predefinita è PostgreSQL. È open source, maturo, gratuito e incredibilmente capace. Gestisce bene sia i dati relazionali classici sia formati moderni come JSON, quindi copre buona parte dei casi NoSQL senza dover aggiungere un secondo sistema.
PostgreSQL offre transazioni affidabili, ricerca full-text integrata, estensioni potenti e una community enorme. Per un’azienda significa una cosa concreta: nessun costo di licenza, nessun vincolo con un fornitore proprietario e la certezza che la tecnologia sarà ancora supportata tra dieci anni. Lo stesso vale per MySQL/MariaDB, che resta un’ottima scelta soprattutto quando il progetto vive su WordPress o su stack già consolidati.
Le domande che mi pongo prima di decidere
Prima di scrivere lo schema dei dati, mi faccio sempre alcune domande che dovrebbe porsi qualsiasi azienda che commissiona un software:
- Quanti dati prevediamo? Centinaia di record o milioni? La risposta cambia l’architettura.
- Quante persone useranno l’app contemporaneamente? La concorrenza ad alto volume richiede scelte diverse.
- I dati sono sensibili? Dati personali e fiscali impongono cifratura, backup e attenzione al GDPR.
- Quanto cambierà la struttura nel tempo? Un prodotto in evoluzione ha bisogno di uno schema gestibile con migrazioni ordinate.
- Qual è il budget di gestione? Un database open source self-hosted ha costi molto diversi da una soluzione cloud gestita.
Rispondere onestamente a queste domande vale più di qualsiasi tabella comparativa trovata online. La tecnologia si sceglie partendo dal problema, non dalla moda del momento.
Performance, backup e sicurezza: dove si vede l’esperienza
Un database scelto bene non basta: va anche configurato e mantenuto. Le performance dipendono molto dagli indici, cioè le strutture che permettono di ritrovare un dato in millisecondi invece di scorrere l’intera tabella. Una query lenta su una tabella da un milione di righe può rendere inutilizzabile un’app che sulla carta era perfetta. È qui che la differenza tra un lavoro fatto bene e uno fatto in fretta diventa evidente.
Poi c’è la protezione dei dati. Ogni database che gestisco ha backup automatici e ripristinabili — un backup che non è mai stato testato non è un backup. Sull’infrastruttura che amministro, le applicazioni girano su server con copie regolari, certificati SSL per cifrare le connessioni e accessi limitati al minimo necessario. Uso Docker e Portainer per isolare i servizi, Nginx o Apache come reverse proxy e HestiaCP per la gestione dell’hosting. Il database non è mai esposto direttamente a Internet.
Questo approccio — costruire e poi operare davvero il prodotto — è ciò che distingue uno sviluppatore che consegna codice e sparisce da chi si assume la responsabilità del funzionamento nel tempo. Le web app che ho realizzato come apicco.app, indelio.eu e tandemops.app non sono demo: sono prodotti reali, costruiti e gestiti da me end-to-end, database compreso.
Self-hosted o cloud gestito?
Un’ultima scelta riguarda dove far vivere il database. Un servizio cloud gestito toglie il pensiero della manutenzione, ma ha costi ricorrenti e mette i dati nelle mani di un fornitore esterno. Una soluzione self-hosted, sulla mia infrastruttura, dà all’azienda pieno controllo, privacy e costi prevedibili. Per molte PMI italiane ed europee, soprattutto quando i dati sono sensibili, questa seconda strada è spesso la più sensata. La valuto sempre insieme al cliente, senza soluzioni preconfezionate.
Vuoi una web app costruita su basi solide?
Scegliere il database per una web app è solo uno dei tasselli, ma è quello su cui poggia tutto il resto. Se la tua azienda ha bisogno di un gestionale, un portale o un’applicazione su misura — progettata bene fin dalle fondamenta e gestita nel tempo da chi l’ha costruita — posso aiutarti dall’idea fino al prodotto in produzione.
Dai un’occhiata ai miei progetti su cornelcaba.com e raccontami cosa hai in mente: scrivimi dalla pagina dei contatti e ti rispondo con una valutazione concreta, senza tecnicismi inutili.
