PostgreSQL
PostgreSQL non è solo un database open source.
È il risultato di quasi quarant’anni di evoluzione accademica e industriale.
Nato nel 1986 all’Università di Berkeley come evoluzione di Ingres, il progetto POSTGRES introduceva concetti che all’epoca erano avanguardia: estendibilità, tipi di dato personalizzati, regole e un modello relazionale avanzato.
Nel 1996 arriva il supporto SQL e il nome cambia in PostgreSQL.
Il mondo però ha continuato a chiamarlo semplicemente “Postgres”.
E va bene così.
In questa sezione esploro PostgreSQL dal punto di vista architetturale e operativo: progettazione, performance, sicurezza e scelte tecniche applicabili in ambienti reali.
Perché usare PostgreSQL non significa solo scegliere un database open source.
Significa scegliere un motore progettato per essere esteso, analizzato e compreso.
VACUUM e autovacuum: perché PostgreSQL ha bisogno che qualcuno pulisca
Un database PostgreSQL da 200 GB con tabelle gonfie il triplo del necessario. L'autovacuum era attivo, ma mal configurato. Come diagnosticare il bloat, leggere pg_stat_user_tables e fare tuning senza disabilitare nulla.
Ruoli e utenti in PostgreSQL: perché è tutto (solo) un ROLE
PostgreSQL non distingue tra utenti e ruoli: tutto è un ROLE. Un modello mentale corretto, un caso reale e un esempio completo per creare un read-only davvero manutenibile.
Quando un LIKE '%valore%' rallenta tutto: un caso reale di ottimizzazione PostgreSQL
Un caso reale di performance in PostgreSQL dove un LIKE '%valore%' ha generato un full scan degradando i tempi di risposta. Analisi del piano di esecuzione e strategia di indicizzazione scalabile.
EXPLAIN ANALYZE non basta: come leggere davvero un piano di esecuzione PostgreSQL
Un caso reale dove l'optimizer ha scelto un nested loop su 2 milioni di righe perché le statistiche erano vecchie. Come leggere un execution plan, trovare i segnali d'allarme e intervenire.