Multigres porta su Supabase un failover che conserva le scritture confermate
L’alpha privata di Multigres su Supabase usa tre nodi Postgres e replica le scritture prima di confermarle, per conservarle anche quando cambia il server principale.
Che succede
Avere una replica di Postgres non basta: se il server principale conferma una scrittura e si guasta prima di copiarla, promuovere quella replica può far sparire un dato già dichiarato salvato. È questo il problema affrontato da Multigres, ora in alpha privata su Supabase.
Il servizio distribuisce Postgres su tre nodi in zone di disponibilità diverse della stessa regione. Le scritture vengono confermate solo dopo essere state replicate su un numero sufficiente di nodi; in caso di guasto, quelli superstiti concordano l’insieme delle scritture confermate prima di promuovere il nuovo primario. L’applicazione continua a usare una stringa di connessione Postgres standard.
L’alpha si attiva alla creazione di nuovi progetti, su invito per organizzazioni con piano a pagamento: fino a due progetti senza costi aggiuntivi durante questa fase. Mancano SLA, Realtime e ripristino a un istante preciso; Supabase non la destina ancora alla produzione.
Perché conta
Il passaggio delicato non è accendere un altro Postgres: è decidere quale copia possa prendere il comando senza smentire un “salvato” già ricevuto dall’applicazione. Supabase sta portando proprio quel coordinamento nel servizio gestito, anche se l’alpha non è ancora pronta per la produzione.
Vuoi sapere di più su pillole come questa?
Nella stessa edizione
Northflank chiede di ruotare tutti i segreti dopo un incidente di sicurezza
Make dà a Claude un browser dentro gli scenari
Maia mostra il piano prima di costruire un’automazione su Make
Nel marketplace di Cursor c’era una versione manomessa di Claude Code
Better Stack porta gli incidenti del servizio dentro Claude
Multigres porta su Supabase un failover che conserva le scritture confermate
Prossima Pillola