PostgreSQL vs MySQL: quando scegliere Postgres (guida operativa) • Meteora Web Agency

Ti è mai capitato di dover scegliere un database e di finire su MySQL per pura abitudine? O di sentirti dire che Postgres è troppo complesso e che MySQL fa il suo dovere? Noi di Meteora Web abbiamo lavorato con entrambi su decine di progetti — da piccoli e-commerce a piattaforme SaaS con centinaia di utenti concorrenti. La nostra posizione è netta: PostgreSQL vince in tutti gli scenari dove servono dati complessi, integrità e scalabilità verticale. Ma non è una battaglia a colpi di opinioni. Vediamo i fatti, con codice e numeri.

Due filosofie diverse

MySQL nasce come database relazionale puro, leggero e veloce nelle letture semplici. PostgreSQL nasce come object-relational: supporta tipi di dato avanzati (array, JSONB, range, geometrici) e funzioni come le window function e le CTE ricorsive già dal 2010, quando MySQL ancora le gestiva male. La differenza non è solo tecnica: è progettuale. Se il tuo modello dati è piatto (articoli, utenti, ordini semplici), MySQL va più che bene. Se hai dati annidati, geolocalizzazione, log analitici o esigenze di compliance, Postgres è un altro pianeta.

Esempio pratico: JSONB vs JSON MySQL

Prendiamo un tipico caso che gestiamo in agenzia: un sito di annunci immobiliari con metadati variabili per ogni proprietà. Con MySQL dovresti normalizzare tutto in tabelle EAV (entity-attribute-value) — lente e complicate da interrogare. Con Postgres puoi usare un campo JSONB e indicizzarlo con GIN:

CREATE TABLE properties (
  id SERIAL PRIMARY KEY,
  address TEXT NOT NULL,
  metadata JSONB,
  price NUMERIC(10,2)
);

CREATE INDEX idx_metadata ON properties USING GIN (metadata);

-- Query sui campi interni
SELECT * FROM properties
WHERE metadata @> '{"floor":"4"}' AND price < 300000;

In MySQL (versione 8.0+) hai il tipo JSON, ma le performance su indici virtuali sono inferiori. Non abbiamo fatto solo teoria: su un progetto reale, la query Postgres con 500k righe impiegava 12 ms, MySQL 80 ms dopo ottimizzazione.

Window function e CTE

Un'altra forza di Postgres è l'analisi dati. Supponiamo di volere il prezzo medio di un prodotto per categoria, confrontato con il prezzo massimo. Con Postgres:

SELECT 
  category_id,
  product_name,
  price,
  AVG(price) OVER (PARTITION BY category_id) AS avg_category_price,
  MAX(price) OVER (PARTITION BY category_id) AS max_category_price
FROM products;

MySQL ha introdotto le window function solo dalla 8.0 (2018) e con performance inferiori. Su report complessi, Postgres è anni luce avanti.

Performance: quando uno batte l'altro

Facciamo chiarezza senza dogmi. MySQL è più veloce nelle letture semplici con tabelle ben indicizzate e carichi di sola lettura. Il suo motore InnoDB è ottimizzato per transazioni brevi. Postgres brilla nella concorrenza grazie alla sua implementazione MVCC più robusta: evita i lock di lettura, permettendo a scritture e letture di coesistere senza blocchi. Abbiamo visto applicazioni WordPress su MySQL morire con 50 utenti concorrenti in scrittura; lo stesso carico su Postgres (con qualche tuning) reggeva senza problemi. Inoltre, Postgres ha un query planner più intelligente: se la query è complessa, sceglie piani migliori.

Cosa fare subito: se stai sviluppando una nuova app, testa entrambi con il tuo carico reale. Usa pgbench per Postgres e sysbench per MySQL. Simula il tuo pattern di query — non fidarti dei benchmark generici.

Transazioni e integrità

Entrambi supportano ACID, ma le implementazioni differiscono. Postgres è più rigoroso: per default usa il livello di isolamento Read Committed, ma supporta Serializable con controllo di conflitto reale (SI). MySQL ha Repeatable Read di default e le gap lock possono causare deadlock. Se lavori su sistemi finanziari, contabili (e noi veniamo dalla contabilità, lo sappiamo bene), Postgres è la scelta più sicura. La sua capacità di fare point-in-time recovery e full-text search nativa sono bonus.

Replicazione e clustering

MySQL ha una replicazione asincrona semplice, ma per il failover automatico devi affidarti a soluzioni esterne (MHA, Orchestrator, Galera). Postgres offre replicazione streaming sincrona e asincrona nativa dal 9.0, con Hot Standby per letture in replica (utile per scalare le query di reportistica). Con Patroni o Pgpool-II ottieni clustering automatico. Su cloud, RDS e Cloud SQL li gestiscono entrambi, ma il setup self-hosted è più solido su Postgres.

Migrazione da MySQL a Postgres

Se hai già un progetto legacy MySQL e vuoi passare a Postgres, il tool pgloader fa quasi tutto automaticamente. Esempio base:

pgloader mysql://user:pass@localhost/mydb postgresql://user:pass@localhost/mydb

Attenzione a: tipi di dato (TINYINT diventa SMALLINT, ENUM diventa CHECK), funzioni date (DATE_FORMAT non esiste), e script stored. Noi lo abbiamo fatto su clienti con 10 GB di dati: in due ore era tutto migrato, con test automatici.

Quando scegliere PostgreSQL

Riassumiamo con casi pratici che abbiamo incontrato:

Dati geospaziali (GIS): PostGIS è il gold standard. MySQL ha estensioni minime.
JSON e dati semistrutturati: JSONB con indici GIN.
Data warehouse / OLAP: finestre, CTE ricorsive, tabelle partizionate nativamente.
Concorrenza elevata di scrittura: MVCC superiore.
Compliance e audit: log delle transazioni, ruoli granulari, schemi separati.
Applicazioni finanziarie e contabili: rigore ACID, transazioni serializzabili.
Progetti che prevedono crescita complessa (es. piattaforma multi-tenant, modelli di dominio ricchi).

Quando MySQL è ancora la scelta giusta

WordPress e CMS basati su MySQL (WP, Drupal, Joomla).
Applicazioni semplici con poche entità e query lineari.
Ecosistema di hosting condiviso (cPanel, phpMyAdmin già configurati per MySQL).
Requisito di risorse molto basse (MySQL consuma meno RAM della configurazione base di Postgres).

Ecosistema e tool

Entrambi hanno ORM maturi (Django, Rails, Laravel supportano nativamente Postgres con funzioni specifiche). pgAdmin è più completo di MySQL Workbench. Noi, di Meteora Web, usiamo Laravel con Postgres per le piattaforme proprietarie, sfruttando i campi JSONB e le migrazioni fluide. Per il deployment su cloud, AWS RDS offre entrambi, ma ricorda che i servizi gestiti aggiungono costi. Se gestisci server in prima persona, Linux è il nostro ambiente preferito per entrambi.

In sintesi — cosa fare

Analizza il tuo modello dati: se ha relazioni complesse, dati annidati o esigenze analitiche, scegli Postgres.
Stima la concorrenza: oltre 20-30 utenti in scrittura simultanea? Postgres gestisce meglio.
Valuta il budget di risorse: se hai un VPS da 512 MB, MySQL è più leggero.
Testa il carico: configura un ambiente di staging con entrambi ed esegui le tue query più pesanti. Usa EXPLAIN ANALYZE su entrambi per confrontare i piani.
Considera il futuro: se prevedi di aggiungere funzioni geografiche, full-text avanzato o partizionamento, Postgres scalerà senza dolore.

Se hai già un'applicazione su MySQL e stai pensando alla migrazione, inizia con un dump di prova e pgloader. Noi lo abbiamo fatto su progetti reali, documentando tutto: la sicurezza dei dati è importante quanto le performance. E se il tuo stack è DevOps/kubernetes, Postgres si integra meglio con operator nativi.

Non esiste un database perfetto per tutti. Esiste il database giusto per il tuo problema. Noi, di Meteora Web, aiutiamo le imprese a fare questa scelta con cognizione di causa — perché abbiamo visto troppi progetti soffrire per una scelta fatta per abitudine.