← Tutti gli articoli

PostgreSQL 17 in produzione: le feature che usiamo davvero

20 May 20262 min di lettura

Da quando 17 è in LTS, lo abbiamo girato sui nostri progetti più grossi. Cosa è valso l'upgrade, cosa è rimasto sulla carta.

PostgreSQL 17 è in produzione sui nostri progetti più grossi da inizio 2026. Sei mesi sono abbastanza per separare la propaganda del rilascio dalla realtà operativa.

Le vittorie misurabili

Vacuum incrementale

Il nuovo memory management di VACUUM ha tagliato del 30-40% il tempo di manutenzione sulle tabelle grosse (10M+ righe). Su un cliente con un'audit log da 200M righe, è passato da 2h notturne a 1h. Per chi ha finestre di manutenzione strette, è la feature singola che giustifica l'upgrade.

JSON_TABLE finalmente standard

JSON_TABLE trasforma un campo JSON in una tabella relazionale. Lo usiamo molto per dati semi-strutturati che arrivano da integrazioni esterne (Stripe webhook, payload di partner B2B). Niente più CTE annidate.

Incremental sort migliorato

Query con ORDER BY a, b dove c'è un indice solo su a: il planner ora sceglie incremental sort molto più aggressivamente. Su dashboard con ordinamenti misti, riduzione del 20-50% sui tempi di risposta senza toccare il codice.

Le feature che non abbiamo (ancora) toccato

BRIN multi-minmax

Promesse interessanti per tabelle storiche enormi, ma nei nostri progetti i casi d'uso reali sono pochi. Più semplice partizionare per data.

Streaming I/O migliorato

Beneficio principalmente per sequential scan su tabelle che non stanno in RAM. Sui nostri carichi, l'I/O è raramente il collo di bottiglia. Per chi gira analytics pure, vale la pena testare.

Cosa cambia per chi viene da Postgres 15

Upgrade quasi sempre liscio: pg_upgrade con --link in 5-10 minuti su DB da 100GB. Le breaking change sono minime — qualche funzione deprecata in plpgsql, niente che blocchi.

Attenzione alle estensioni: pg_repack, postgis, timescaledb hanno tempi di adeguamento diversi. Verificare la versione compatibile prima di pianificare l'upgrade.

Cosa NON è migliorato

  • Replication lag su carichi write-heavy: non c'è il salto di qualità promesso da chi parla di "20% performance gain" senza specificare.
  • Logical replication su DDL: ancora richiede workaround. Promesso per 18 (forse).

Bilancio

Per chi è su 14 o 15: upgrade fortemente consigliato per metà 2026. Per chi è già su 16: aspettare la 18 può avere senso, salvo bisogno specifico di VACUUM più veloce o JSON_TABLE.