OrioleDB : un Postgres sans tuples morts, en bêta

Ce qui se passe

Supabase ouvre en bêta publique, sur tous ses plans et au prix de Postgres standard, OrioleDB, un moteur de stockage open source pour Postgres. Il se choisit à la création d'un projet. La bêta embarque OrioleDB beta19 sur Postgres 17.11. Redimensionnement, réplicas en lecture, montées de version et sauvegardes planifiées fonctionnent ; la production, pas encore.

Le problème visé

Le stockage par défaut de Postgres, le heap, ne modifie jamais une ligne sur place : chaque mise à jour écrit une nouvelle version et laisse l'ancienne derrière elle, un tuple mort. Comme les index pointent vers l'emplacement physique de la ligne, la nouvelle version demande en général une entrée dans chaque index, même ceux dont la colonne n'a pas bougé. VACUUM et l'autovacuum nettoient ; quand ils prennent du retard, tables et index gonflent et les requêtes lisent plus de pages. D'où les réglages d'autovacuum par table, les VACUUM programmés ou pg_repack.

Ce qu'OrioleDB change

Il se branche par la Table Access Method, l'interface de Postgres pour les moteurs de stockage : chaînes de connexion, Auth, politiques RLS et bibliothèques clientes ne bougent pas.

• Journal d'annulation : l'ancienne version d'une ligne y part et est récupérée automatiquement ; dans la plupart des cas, plus de tuples morts, donc rien pour VACUUM.
• Identifiants de transaction sur 64 bits pour ses tables : plus de bouclage qui bloque les écritures. Les catalogues système et les tables heap restent en 32 bits.
• Tables organisées par index : la ligne vit dans l'index de clé primaire, une recherche par clé lit une seule structure, et les index secondaires pointent vers la clé — une mise à jour n'écrit que dans les index des colonnes modifiées. Sans clé primaire, une clé cachée est créée.
• Pas de table de correspondance des tampons et lectures de pages sans verrou, checkpoints en copie sur écriture et WAL au niveau de la ligne.

Les chiffres, et d'où ils viennent

Ils sortent de DBArena, le banc de Supabase — donc de l'éditeur —, avec une charge dérivée de TPC-C, non comparable aux résultats TPC-C officiels. Code, méthode et résultats bruts sont publics.

• Données quatre fois plus grosses que la mémoire, instance 8XL (32 vCPU, 128 Gio) : 113 850 transactions par minute, environ 1,8 fois le heap. En taille Small, environ 46 % de débit par dollar en plus.
• Données en mémoire : +13 % en Large, +29 % en 8XL, et le heap devant en Small.

Les gains attendus portent sur les tables souvent modifiées ou purgées (statuts de commande, stocks, files de jobs, sessions), les données plus grosses que la mémoire, la forte concurrence et les lectures par clé primaire. Une charge surtout en lecture qui tient en mémoire verra peu de différence.

Les limites de la bêta

• Ni SLA, ni restauration à un instant donné (PITR), ni restauration d'une sauvegarde vers un nouveau projet.
• Choix définitif : impossible d'ajouter OrioleDB à un projet existant ou de le retirer.
• Les B-tree natifs sont les plus rapides ; les autres index, dont pgvector HNSW, passent par un pont expérimental.
• CLUSTER, VACUUM FULL et quelques autres commandes ne marchent pas sur ces tables.
• Image sans plv8, plls, plcoffee ni timescaledb-apache.
• SERIALIZABLE verrouille par défaut chaque table touchée (réglage orioledb.serializable).
• Incompatible avec Multigres dans un même projet, absent de Supabase auto-hébergé ; les projets de l'alpha ne sont pas migrés.

Comment l'essayer

En local, avec la CLI Supabase 2.119.0 ou plus :

supabase init --use-orioledb

Les nouvelles tables utilisent alors OrioleDB, sans syntaxe particulière. Rejouez votre propre charge avant de conclure, ce que recommande aussi l'éditeur.

Source : Supabase, en anglais. Code : orioledb/orioledb.