Supabase porta OrioleDB in beta pubblica
Supabase ha aperto la beta pubblica di OrioleDB su tutti i piani. OrioleDB è un motore di storage open source per Postgres: cambia il modo in cui vengono salvate le righe delle tabelle, così nella maggior parte dei casi non si gonfiano quando i dati cambiano spesso. Si sceglie quando si crea un progetto e costa come Postgres standard, ma per ora non è pronto per la produzione.
Il problema delle tabelle che si gonfiano
- Postgres salva le righe nell'heap. Un update non modifica la riga: ne scrive una nuova versione e lascia la vecchia come dead tuple, una riga morta. Lo stesso succede con le cancellazioni.
- La nuova versione di solito richiede una voce nuova in tutti gli indici della tabella, anche in quelli su colonne che non sono cambiate.
- A ripulire ci pensa autovacuum, che sulle tabelle con tanti update e delete resta indietro: tabelle e indici crescono più dei dati (il bloat) e le query rallentano. Molti team regolano autovacuum tabella per tabella o ricostruiscono le tabelle con pg_repack.
Come funziona OrioleDB
Sostituisce l'heap tramite la Table Access Method, l'interfaccia di Postgres per i motori di storage. Stringhe di connessione, Auth, policy di Row Level Security e librerie client restano uguali.
- Undo log: la versione precedente di una riga finisce in un registro che si libera da solo, quindi di solito non resta niente da pulire per VACUUM.
- ID di transazione a 64 bit: quelli di Postgres sono a 32 bit e ricominciano da capo, e se VACUUM resta indietro Postgres smette di accettare scritture. Le tabelle OrioleDB non hanno questo problema (cataloghi di sistema e tabelle heap restano a 32 bit).
- Tabelle organizzate per indice: le righe stanno dentro l'indice della chiave primaria, così una ricerca per chiave legge una struttura sola e un update scrive solo negli indici delle colonne cambiate.
- Letture senza lock: le pagine in memoria sono collegate direttamente a quelle su disco, senza la contesa sul buffer condiviso di Postgres.
- Checkpoint copy-on-write e WAL a livello di riga: si scrivono solo i dati cambiati, con meno I/O quando si scrive molto.
OrioleDB è in sviluppo dal 2021 e i suoi autori fanno parte del team Supabase. La beta usa OrioleDB beta19 su Postgres 17.11.
Le prestazioni
Supabase lo misura su DBArena, il suo sito di benchmark aperto: un carico derivato da TPC-C (non confrontabile coi risultati TPC-C ufficiali) su Supabase Postgres, Supabase con OrioleDB, Amazon RDS e Google Cloud SQL, in sette taglie, con i dati in memoria oppure quattro volte più grandi della memoria. Codice, metodo e risultati grezzi sono pubblici.
- Con i dati più grandi della memoria OrioleDB ha il miglior throughput per dollaro fra tutti i prodotti, a ogni taglia.
- Su un'istanza 8XL (32 vCPU, 128 GiB di RAM) fa circa 1,8 volte le transazioni al minuto di Postgres con heap: 113.850 al minuto.
- Sulla taglia Small, a parità di prezzo, dà circa il 46% di throughput per dollaro in più dell'heap.
- Con i dati in memoria il distacco si riduce: circa +13% sulla Large e +29% sulla 8XL, mentre sulla Small vince l'heap.
Rende di più su tabelle aggiornate o cancellate spesso (stato degli ordini, giacenze, code di job, sessioni), con dati più grandi della memoria, tante connessioni insieme e query per chiave primaria. Gli indici non B-tree, come HNSW di pgvector, passano da un ponte sperimentale e potrebbero non migliorare ancora: Supabase consiglia di misurare il proprio carico.
Come provarlo
Dalla Dashboard: Create a new project, poi Advanced Configuration, e in Postgres Type si sceglie Postgres with OrioleDB. Le nuove tabelle lo usano di default, senza sintassi speciale. In locale serve la Supabase CLI 2.119.0 o successiva con supabase init --use-orioledb. Ridimensionamento di calcolo e disco, repliche di lettura, aggiornamenti di Postgres e backup programmati funzionano già.
Limiti della beta
- Solo per test: niente SLA e niente produzione.
- Si sceglie alla creazione: non si aggiunge a un progetto esistente e non si toglie dopo.
- Niente Point-in-Time Recovery né ripristino di un backup in un nuovo progetto.
- Non funzionano CLUSTER, VACUUM FULL e pochi altri comandi; mancano le estensioni plv8, plls, plcoffee e timescaledb-apache.
- Un progetto usa OrioleDB oppure Multigres, non tutti e due, e non c'è ancora nella versione self-hosted di Supabase.
Cosa significa
Supabase ha annunciato la beta all'evento Supabase Select, insieme a Multigres e DBArena, con l'obiettivo dichiarato di togliere uno a uno i limiti di scala di Postgres. Per chi ha tabelle che cambiano di continuo, OrioleDB promette meno manutenzione di VACUUM e più resa dalla stessa macchina, senza toccare il codice dell'app. Ma resta una beta: da provare su un progetto nuovo, non da mettere in produzione.
