Note di Matteo

Migrating from DigitalOcean to Hetzner: From $1,432 to $233/month With Zero Downtime. Contiene utili istruzioni su come migrare un database MySQL enorme con quasi-zero downtime.

Scaling Postgres connections with PgBouncer. Mega-tutorial di PlanetScale su come usare PgBouncer, il connection pooler per PostgreSQL.

Automating RDS Postgres to Aurora Postgres Migration. Netflix spiega come ha migrato centinaia di cluster AWS RDS PostgreSQL verso RDS Aurora PostgreSQL (una versione di PostgreSQL più scalabile sviluppata e gestita da AWS).

Il copione è più o meno il solito delle migrazioni di database: attivare un nuovo cluster in replica del cluster originale (es. logical replication) e poi pianificare attentamente uno switchover. Lo switchover comporta del downtime perché bisogna bloccare le scritture sul vecchio cluster, ed è interessante vedere che anche Netflix non riesce a scampare a questa regola.

Nel loro caso il disservizio per ciascuno dei cluster è stato di 10 minuti o meno, specialmente per il riavvio forzato di RDS usato per interrompere forzatamente tutte le connessioni esistenti, anche se in teoria già bloccate dal security group. Comunque lettura interessante.

How to build a distributed queue in a single JSON file on object storage. Usare l'object storage come un database è sempre affascinante e Turbopuffer ci ha costruito sopra un vector db. Ora hanno implementato anche la coda di indicizzazione dei dati in un singolo file queue.json in un bucket S3/GCS, sfruttando le primitive dell'object storage (come compare-and-set, o CAS) per gestire conflitti (è in realtà un po' più complicato di così e l'articolo è scritto molto bene).

Introduction to PostgreSQL Indexes è una buona introduzione ai concetti attorno agli indici di PostgreSQL, partendo da come i dati sono serializzati su disco, come gli indici agevolano la ricerca e come funzionano B-tree, Hash, BRIN, ecc. anche con nuove funzioni come "skip scan" di PostgreSQL 18.

OpenAI ha pubblicato un articolo in cui spiega meglio la strategia di scaling di PostgreSQL: un server primario read-write e 50 replica read-only per supportare 800 milioni di utenti. Ma è di fatto in corso una migrazione verso database più scalabili come Azure Cosmos DB:

To mitigate these limitations and reduce write pressure, we’ve migrated, and continue to migrate, shardable (i.e. workloads that can be horizontally partitioned), write-heavy workloads to sharded systems such as Azure Cosmos DB, optimizing application logic to minimize unnecessary writes. We also no longer allow adding new tables to the current PostgreSQL deployment. New workloads default to the sharded systems.

Azure Cosmos DB è un database managed globalmente distribuito e a scalabilità essenzialmente illimitata, l'equivalente di DynamoDB di AWS ma, mi sembra di capire, con anche il supporto al modello relazionale e non solo NoSQL/a documenti (Azure Cosmos DB for PostgreSQL). Con garanzie di consistency che possono essere diverse da un classico database relazionale con scritture single-node, in base alla configurazione di sharding dell'estensione Citus.

Dopo Quickwit scopro Nixiesearch, essenzialmente un Elasticsearch backed by object storage (S3, ecc.).

SlateDB. slatedb is an OSS embedded key-value database built on object storage.

pg_repack. pg_repack is a PostgreSQL extension which lets you remove bloat from tables and indexes, and optionally restore the physical order of clustered indexes. Unlike CLUSTER and VACUUM FULL it works online, without holding an exclusive lock on the processed tables during processing. pg_repack is efficient to boot, with performance comparable to using CLUSTER directly.

Postmortem di Railway, la creazione di un indice PostgreSQL ha tirato giù tutto:

A routine change to this Postgres database introduced a new column with an index to a table containing approximately 1 billion records. This table is critical in our backend API’s infrastructure, used by nearly all API operations.

The index creation did not use Postgres’ CONCURRENTLY option, causing an exclusive lock on the entire table. During the lock period, all queries against the database were queued behind the index operation. [...] Manual intervention attempts to terminate the index creation failed.

Le misure:

We’re going to introduce several changes to prevent errors of this class from happening again:

• In CI, we will enforce CONCURRENTLY usage for all index creation operations, blocking non-compliant pull requests before merge.
• PgBouncer connection pool limits will be adjusted to prevent overwhelming the underlying Postgres instance's capacity.
• Database user connection limits will be configured to guarantee administrative access during incidents, ensuring maintenance operations remain possible under all conditions.

Numeri sulla migrazione di Mezmo da Elasticsearch a Quickwit.

Con Elasticsearch:

• 2 PB di storage
• 275 istanze EC2
• 35 TB di RAM
• 7770 core

(800 MB - 2 GB di integestion al secondo)

Con Quickwit (che è pazzesco!):

• -80% storage
• -40% di instanze EC2
• -98% RAM
• -93% CPU

PostgreSQL extensions on cloud monitora quali estensioni sono presenti su quali cloud provider che offrono PostgreSQL managed. Utile! E dato che OVHcloud e UpCloud si basano su tecnologia Aiven, sono implicitamente inclusi nel confronto.

I database PostgreSQL managed di Ubicloud sono ora anche su infrastruttura AWS. Ubicloud è olandese anche se controllata da Ubicloud Inc., statunitense.

How TimescaleDB helped us scale analytics and reporting. Recente articolo molto interessante di Cloudflare su TimescaleDB, estensione PostgreSQL e alternativa molto più semplice a ClickHouse per gestire dati di analytics, quando PostgreSQL semplice non ci sta più dietro.

TIL in PostgreSQL ALTER DEFAULT PRIVILEGES si applica solo agli oggetti creati dal ruolo che ha creato i default privileges. Di default è il ruolo attualmente connesso, ma si può specificare:

ALTER DEFAULT PRIVILEGES
FOR ROLE prod_dmarcwise
IN SCHEMA public
GRANT SELECT ON TABLES TO prod_pgdump;