Le paysage des bases de données pour les applications modernes est en constante évolution, avec les paradigmes serverless et distribués repoussant les limites du possible avec les données relationnelles. En tant que professionnels, nous avons été témoins d'avancées significatives au cours de l'année écoulée, en particulier au sein de l'écosystème PostgreSQL, alors que des plateformes comme Supabase, Neon et même PlanetScale, traditionnellement centrée sur MySQL, se disputent la suprématie en offrant des solutions robustes, évolutives et conviviales pour les développeurs. Il ne s'agit pas de battage médiatique ; il s'agit des changements architecturaux tangibles, des gains de performance et des efficacités opérationnelles qui deviennent essentiels pour les déploiements en production.
Ayant récemment testé ces plateformes, j'ai observé une tendance claire : la désagrégation du calcul et du stockage, la gestion sophistiquée des connexions et la recherche incessante de workflows de développement de type "Git" ne sont plus des fonctionnalités ambitieuses, mais des conditions sine qua non. Les chiffres racontent une histoire intéressante, révélant à la fois des progrès impressionnants et des défis persistants.
Le sable mouvant des architectures de bases de données : du monolithe aux microservices
Le déploiement PostgreSQL traditionnel, bien que robuste, a souvent du mal à répondre aux exigences des fonctions serverless modernes et des applications distribuées à l'échelle mondiale. Le couplage inhérent entre le calcul et le stockage dans une instance PostgreSQL standard crée des goulots d'étranglement pour la mise à l'échelle indépendante et introduit des complexités pour la haute disponibilité et la reprise après sinistre. Au cours de l'année écoulée, ces plateformes ont redoublé d'efforts pour mettre en œuvre des architectures qui répondent fondamentalement à ces limitations.
Neon, en particulier, a fondé l'ensemble de sa proposition sur cette désagrégation. Leur architecture sépare le processus de calcul PostgreSQL, qui s'exécute en tant que microservice stateless, d'une couche de stockage durable et multi-tenant. Cette conception signifie qu'une instance PostgreSQL peut être lancée ou arrêtée à la demande, en ne tirant du stockage que les données nécessaires pour répondre aux requêtes. Il s'agit d'un changement significatif par rapport aux configurations traditionnelles où une seule instance contrôle le stockage local, simplifiant les sauvegardes, la réplication logique et le provisionnement de réplicas en lecture seule. La couche de stockage elle-même est conçue comme un magasin clé-valeur, intégré au stockage d'objets cloud comme Amazon S3 ou Google Cloud Storage pour la durabilité et l'évolutivité.
Supabase, tout en offrant une instance PostgreSQL gérée, a fait évoluer ses services environnants pour adopter des modèles plus orientés microservices. Leur migration vers une architecture de plateforme v2, achevée pour les plans payants et progressivement déployée sur les plans gratuits à partir de mars 2024, découple les services tels que Storage, Realtime et le pool de connexions (PgBouncer). Auparavant, il s'agissait de services à instance unique par projet. L'architecture v2 les déplace vers un modèle multi-tenant, où une seule instance dessert de nombreux projets. Cela vise à libérer des ressources pour les bases de données PostgreSQL, à activer des fonctionnalités plus gourmandes en ressources et à ouvrir la voie à des capacités telles que la mise à l'échelle sans temps d'arrêt. Il s'agit d'une optimisation pratique, permettant à Supabase d'offrir une meilleure utilisation des ressources et potentiellement des performances plus stables pour sa base d'utilisateurs.
L'évolution architecturale de Supabase : l'Edge et les capacités en temps réel
Supabase continue d'affiner son écosystème autour de PostgreSQL, avec des avancées notables dans ses Edge Functions et ses capacités en temps réel. L'engagement de la plateforme à fournir un backend-as-a-service (BaaS) complet basé sur des normes ouvertes reste fort.
Edge Functions : rapprocher le calcul des utilisateurs
Les Edge Functions de Supabase, alimentées par Deno, sont des fonctions TypeScript distribuées globalement conçues pour s'exécuter à proximité de l'utilisateur, minimisant la latence des requêtes HTTP. Pour un aperçu plus approfondi de la façon dont cela se compare à d'autres runtimes edge, consultez Cloudflare vs. Deno : La vérité sur le Edge Computing en 2025. Les mises à jour récentes en 2025 ont rendu le déploiement et la gestion de ces fonctions plus rationalisés, avec des options de déploiement directes à partir du tableau de bord et de la CLI Supabase.
Un aspect essentiel pour les développeurs est la façon dont ces Edge Functions interagissent avec la base de données PostgreSQL. Bien que Supabase fournisse une API RESTful générée automatiquement (PostgREST) et une API GraphQL, les Edge Functions peuvent également se connecter directement à la base de données à l'aide de n'importe quel client PostgreSQL populaire. Cela permet d'exécuter du SQL brut dans la fonction, une fonctionnalité puissante pour une logique personnalisée qui exige une faible latence et un accès direct aux données.
Considérez un scénario où vous devez effectuer une validation personnalisée ou une transformation des données avant de les écrire dans la base de données, ou déclencher une requête complexe basée sur un webhook entrant. Une Edge Function peut intercepter la requête, effectuer la logique, puis interagir avec PostgreSQL. Par exemple, en utilisant le pilote Deno Postgres :
// supabase/functions/my-edge-function/index.ts
import { Pool } from 'https://deno.land/x/postgres@v0.17.0/mod.ts'; //
Deno.serve(async (req) => {
try {
const { some_data } = await req.json();
// Établir un pool de connexions à la base de données
// En production, l'URL de la base de données est automatiquement configurée avec SSL.
const pool = new Pool(Deno.env.get('DATABASE_URL'), 1);
const connection = await pool.connect();
try {
// Exemple : Insérer des données après une certaine validation
const result = await connection.queryObject`
INSERT INTO public.my_table (data_field)
VALUES (${some_data})
RETURNING id;
`;
return new Response(JSON.stringify({ id: result.rows[0].id }), {
headers: { 'Content-Type': 'application/json' },
status: 200,
});
} finally {
connection.release();
}
} catch (err) {
return new Response(String(err?.message ?? err), { status: 500 });
}
});
Cette connexion directe contraste avec les interactions côté client, où l'API PostgREST est souvent préférée pour son application intégrée de RLS et sa sérialisation JSON. Pour les Edge Functions, la nature côté serveur rend les connexions TCP directes réalisables et souvent plus performantes pour les opérations complexes et avec état.
Temps réel : Réplication logique PostgreSQL à l'échelle
La fonctionnalité Realtime de Supabase est un différenciateur clé, permettant des mises à jour en direct pour les applications de chat, les outils collaboratifs et les tableaux de bord. Leur architecture tire parti de la fonctionnalité de réplication logique de PostgreSQL pour diffuser les modifications de la base de données. Contrairement à la réplication physique, qui envoie des fichiers binaires, la réplication logique transmet les modifications de données (insertions, mises à jour, suppressions) sous forme de messages logiques, permettant des abonnements précis au niveau de la table.
Le cœur de ce système implique que Supabase crée des slots de réplication sur PostgreSQL pour diffuser les entrées Write-Ahead Log (WAL). Ces entrées WAL sont ensuite analysées et émises sous forme de charges utiles JSON aux clients via des connexions WebSocket. Cette conception permet une évolutivité horizontale en découplant la base de données de la couche de diffusion en temps réel, en prenant en charge plusieurs abonnés avec un minimum de surcharge. Supabase utilise un serveur Elixir/Phoenix pour son infrastructure Realtime, un choix délibéré en raison des forces d'Elixir dans la gestion des connexions simultanées et de la messagerie à faible latence. Cette infrastructure personnalisée a été construite pour surmonter les limitations du mécanisme natif NOTIFY/LISTEN de PostgreSQL, en particulier sa limite de charge utile de 8000 octets, qui serait insuffisante pour les capacités de temps réel de niveau entreprise.
Le service Realtime fournit également Broadcast pour les messages éphémères et Presence pour le suivi de l'état partagé, allant au-delà des simples notifications de modification de la base de données. Cette approche en couches offre aux développeurs des outils puissants pour créer des applications dynamiques sans connaissance approfondie des internes de la réplication PostgreSQL.
Neon's Serverless PostgreSQL : La désagrégation en pratique
Neon a toujours été un fervent défenseur de la désagrégation du calcul et du stockage comme le changement fondamental pour PostgreSQL serverless. Leur architecture est une réponse directe aux limitations de PostgreSQL traditionnel dans les environnements serverless et cloud-native.
Séparation du calcul et du stockage : l'innovation centrale
L'architecture de Neon divise le monolithe PostgreSQL en une couche de calcul stateless et une couche de stockage multi-tenant durable. Les nœuds de calcul, qui sont des instances PostgreSQL standard, deviennent éphémères. Lorsqu'une base de données est inactive pendant une période configurable (par exemple, cinq minutes), le nœud de calcul est arrêté, passant à l'échelle zéro. Lors d'une nouvelle connexion, un nœud de calcul est rapidement lancé dans un conteneur Kubernetes, se connectant au système de stockage existant sans avoir besoin de restaurer les données. Cette capacité de "mise à l'échelle zéro" est un mécanisme d'économie de coûts significatif pour les charges de travail intermittentes.
La couche de stockage est un système append-only en couches conçu pour les magasins d'objets, fournissant la durabilité et permettant des fonctionnalités telles que le voyage dans le temps et le branching. Les écritures dans la base de données sont diffusées sous forme d'enregistrements WAL vers les WAL safekeepers, qui garantissent la durabilité grâce à un mécanisme de consensus basé sur Paxos avant d'être traitées par le pageserver et téléchargées vers le stockage d'objets. Ce système de stockage robuste permet une mise à l'échelle indépendante des ressources de calcul et de stockage.
Pour atténuer la latence de "démarrage à froid" inhérente à la mise à l'échelle du calcul à zéro, Neon utilise des stratégies telles que le pooling de connexions via PgBouncer. PgBouncer permet à Neon de prendre en charge jusqu'à 10 000 connexions simultanées en maintenant un pool de connexions à PostgreSQL, réduisant ainsi la surcharge de l'établissement de nouvelles connexions de base de données pour chaque requête client.
Les développeurs peuvent choisir entre des chaînes de connexion directes et groupées. Pour les fonctions serverless et la haute concurrence, la chaîne de connexion groupée, identifiable par l'option -pooler dans le nom d'hôte (par exemple, ep-neon-db.pooler.neon.tech), est fortement recommandée.
// Exemple de connexion à Neon avec le pooling
import { Pool } from '@neondatabase/serverless';
const connectionString = process.env.DATABASE_URL_POOLED; // par exemple, postgres://user:pass@ep-neon-db.pooler.neon.tech/dbname
const pool = new Pool({ connectionString });
export async function handler(event) {
const client = await pool.connect();
try {
const res = await client.query('SELECT NOW()');
return {
statusCode: 200,
body: JSON.stringify({ time: res.rows[0].now }),
};
} finally {
client.release();
}
}
Branching de type Git et voyage dans le temps
L'une des fonctionnalités phares de Neon, et un facteur d'amélioration significatif de la productivité, est sa fonctionnalité de branching de type Git. Grâce à son architecture de stockage copy-on-write, la création d'une nouvelle branche est une opération instantanée, quelle que soit la taille de la base de données. Cette nouvelle branche est une copie complète et isolée des données et du schéma de la branche parente au moment de la création, mais elle ne stocke que le delta des modifications, ce qui la rend extrêmement rentable.
Cela permet des workflows de développement puissants :
- Développement de fonctionnalités : Les développeurs peuvent créer une branche pour chaque nouvelle fonctionnalité, expérimenter sans affecter la production et supprimer facilement la branche.
- Tests : Lancez une branche de base de données dédiée pour chaque exécution de pipeline CI/CD ou déploiement de prévisualisation. L'intégration de Neon avec Vercel, par exemple, peut créer automatiquement une branche pour chaque déploiement de prévisualisation.
- Récupération à un point dans le temps (PITR) : Neon conserve un historique des modifications (enregistrements WAL) pendant une fenêtre de restauration configurable (par exemple, 6 heures en Free, jusqu'à 30 jours sur les plans Scale). Cela permet aux utilisateurs de créer une branche à partir de n'importe quel point dans le passé au sein de cette fenêtre, permettant effectivement de "remonter dans le temps" pour se remettre d'erreurs ou analyser des états historiques.
La CLI neonctl est essentielle à la gestion de ces branches :
# Créer une nouvelle branche à partir de 'main'
neonctl branch create my-feature-branch --parent-branch-name main
# Créer une branche à partir d'un point spécifique dans le temps (par exemple, il y a 1 heure)
neonctl branch create bugfix-branch --parent-branch-name production --point-in-time "1 heure ago"
# Lister les branches
neonctl branch list
Chaque branche obtient son propre point de terminaison de calcul autoscalable indépendant, évitant les problèmes de "mauvais voisin" et garantissant des performances constantes. Lorsqu'elles sont inactives, ces branches sont également réduites à zéro, optimisant les coûts.
PlanetScale's Vitess-Powered MySQL : Un regard comparatif sur PostgreSQL
Bien que PlanetScale ait historiquement été synonyme de Vitess-powered MySQL, son entrée récente dans l'espace PostgreSQL géré avec PlanetScale for Postgres et le projet Neki en cours pour PostgreSQL fragmenté est significatif. Cela offre une excellente occasion de comparer et de contraster les philosophies architecturales, en particulier en ce qui concerne l'évolutivité horizontale.
Le modèle de fragmentation de Vitess et son influence
Vitess, né chez YouTube, est un système de clustering de bases de données qui permet une mise à l'échelle horizontale de MySQL grâce à une fragmentation explicite. Il y parvient en acheminant les requêtes via des proxys VTGate, qui comprennent le schéma de fragmentation et dirigent les requêtes vers les fragments appropriés. Vitess abstrait la complexité de la fragmentation de la couche applicative, permettant aux applications d'interagir avec ce qui apparaît comme une seule base de données MySQL monolithique.
Les dernières versions de Vitess, telles que Vitess 21 (octobre 2024) et Vitess 23 (novembre 2025), se sont concentrées sur l'amélioration de la compatibilité des requêtes, l'amélioration de la gestion du cluster et l'extension des capacités VReplication. Vitess 21 a introduit la prise en charge expérimentale des transactions distribuées atomiques et des CTE récursives, résolvant des limitations de longue date dans SQL distribué. Vitess 23 a affiné davantage les métriques pour le routage des transactions et le comportement des fragments, et a mis à niveau sa version MySQL par défaut vers 8.4.6, signalant un engagement envers la compatibilité future.
PlanetScale for Postgres et Project Neki
PlanetScale a officiellement lancé son service PostgreSQL géré, conçu pour la performance et la fiabilité sur AWS ou Google Cloud, fin 2025. Cette offre tire parti de ses clusters "Metal", qui sont construits sur des disques NVMe locaux pour fournir des "IO illimités" et des latences considérablement plus faibles par rapport aux instances basées sur EBS traditionnelles. Le cluster M-10, à partir de 50 $/mois, rend les performances NVMe plus accessibles.
Le développement essentiel ici est le projet Neki, l'initiative de PlanetScale visant à apporter la fragmentation de type Vitess à PostgreSQL. Contrairement à Vitess, qui était open source dès le départ, Neki est conçu à partir de principes fondamentaux, tirant des leçons de Vitess mais pas en tant que fork. Cela indique un investissement sérieux dans la résolution des défis de mise à l'échelle horizontale de PostgreSQL à un niveau fondamental, plutôt que de simplement adapter une solution MySQL existante.
Pendant ce temps, Supabase a également fait un mouvement significatif dans l'espace de fragmentation PostgreSQL en recrutant Sugu Sougoumarane, co-créateur de Vitess, pour diriger le projet Multigres. Multigres vise à apporter la fragmentation à PostgreSQL, en partant de zéro mais en se concentrant sur la compatibilité et la convivialité, en tirant parti du parcours de Vitess. Cela signale une course fascinante pour fournir des solutions de fragmentation PostgreSQL natives robustes.
Benchmarking la promesse du "Serverless" : Latence, débit et coût
La promesse des bases de données serverless est l'élasticité, la faible surcharge opérationnelle et l'efficacité des coûts. Cependant, ces avantages s'accompagnent souvent de caractéristiques de performance qui diffèrent des instances provisionnées traditionnelles.
Latence de démarrage à froid et gestion des connexions
L'un des compromis les plus fréquemment discutés dans les environnements serverless est la latence de démarrage à froid. Pour Neon, lorsque le nœud de calcul est mis à l'échelle à zéro, sa réactivation peut prendre de 500 ms à quelques secondes, selon des facteurs tels que la taille de la base de données et la charge de travail. Cette latence peut être problématique pour les requêtes synchrones, orientées utilisateur.
Neon atténue cela avec son pooler de connexions (PgBouncer). En utilisant une chaîne de connexion groupée, les applications se connectent à PgBouncer, qui maintient des connexions ouvertes à l'instance PostgreSQL sous-jacente. Cela réduit considérablement la surcharge de l'établissement d'une nouvelle connexion TCP et de l'authentification auprès de PostgreSQL pour chaque requête client, masquant ainsi une partie de la latence de démarrage à froid de la perspective de l'application.
Démarrage à froid comparatif (illustratif, pas un benchmark direct) :
- Neon (calcul mis à l'échelle à zéro) : ~500 ms - 2 s (première connexion après inactivité)
- Fonction Edge Supabase (démarrage à froid) : ~100 ms - 500 ms (première invocation après inactivité)
- PlanetScale (Metal provisionné) : Latence de démarrage à froid quasi nulle en raison des instances toujours actives.
Débit et performances d'E/S
Pour les charges de travail soutenues, l'infrastructure sous-jacente devient primordiale. Les clusters "Metal" de PlanetScale, avec des disques NVMe locaux, visent explicitement un débit élevé et une faible latence. Ils revendiquent des "IOPS illimités" où les clients atteignent généralement les limites du CPU avant les goulots d'étranglement des E/S, avec des latences p95 passant de ~45 ms à 5 à 10 ms après la migration vers Metal.
Le modèle de stockage désagrégé de Neon, bien qu'il permette l'élasticité, introduit des sauts réseau entre le calcul et le stockage. Pour contrer une éventuelle dégradation des performances, Neon utilise un cache de fichiers local (LFC) entre les buffers partagés de PostgreSQL et le stockage distant. Ce LFC tire parti du cache de pages Linux, visant à fournir des latences de type RAM pour les données fréquemment consultées, débordant sur le disque lorsque le LFC dépasse la capacité de la RAM.
Les performances de Supabase sont liées à son fournisseur de cloud sous-jacent et à l'allocation de ressources de ses instances PostgreSQL gérées. L'évolution de l'architecture v2 vers des modèles orientés microservices pour les services tels que Realtime et Storage vise à fournir des ressources plus dédiées à la base de données elle-même, améliorant potentiellement les performances de base et la cohérence.
Modèles de coûts
- Neon : Tarification basée sur la consommation, la mise à l'échelle du calcul à zéro en cas d'inactivité, ce qui le rend très rentable pour le développement, les tests et les charges de travail en rafale.
- Supabase : Offre un plan gratuit généreux, avec des plans payants basés sur les heures de calcul, le stockage et les messages en temps réel.
- PlanetScale : Historiquement connu pour sa tarification basée sur l'utilisation pour Vitess, sa nouvelle offre PostgreSQL comprend des clusters
Metalà partir de 50 $/mois, offrant une option dédiée et performante.
Expérience développeur et intégration de l'écosystème : CLI, API et frameworks
La prouesse technique d'une plateforme n'est aussi bonne que sa convivialité. Les trois plateformes accordent la priorité à l'expérience développeur grâce à des outils CLI robustes, des API complètes et une intégration transparente avec les piles de développement modernes.
- CLI Supabase : La
CLI supabaseest un outil central pour le développement local, la gestion des migrations et le déploiement des Edge Functions. Les mises à jour récentes en 2025 incluent la possibilité de déployer des Edge Functions à partir de la CLI sans Docker. - CLI Neon (
neonctl) :neonctloffre un contrôle complet sur les projets Neon, y compris la création et la gestion des branches. Il est essentiel pour automatiser les workflows CI/CD. - CLI PlanetScale : La CLI de PlanetScale est bien considérée pour la gestion des clusters Vitess et s'étend désormais à ses offres PostgreSQL, permettant aux développeurs d'interagir avec les workflows de branching et les modifications de schéma.
L'avenir : défis et schémas émergents
Malgré les progrès rapides, plusieurs défis persistent et de nouveaux schémas émergent. La réalisation de déploiements PostgreSQL véritablement cohérents et forts dans plusieurs régions reste complexe. La fragmentation, comme poursuivie par Neki (PlanetScale) et Multigres (Supabase), est un pas vers la mise à l'échelle horizontale, mais garantir des lectures et des écritures cohérentes et fortes à faible latence dans des régions géographiquement éloignées est un problème plus difficile.
Le "cycle de l'IA" a également un impact profond sur l'innovation des bases de données. PlanetScale a annoncé la disponibilité générale de la prise en charge des vecteurs dans MySQL en avril 2025, permettant de stocker des données vectorielles aux côtés des données relationnelles. Supabase prend également en charge depuis longtemps pgvector pour la recherche de similarité efficace. Cette tendance suggère que les bases de données deviendront plus "intelligentes", non seulement stockant des données, mais participant également activement à leur interprétation et à leur application dans les workflows d'IA.
Conclusion : considérations pratiques pour les déploiements en production
Les développements récents chez Supabase, Neon et PlanetScale soulignent un écosystème dynamique et en évolution rapide pour PostgreSQL. Chaque plateforme offre des avantages distincts pour des cas d'utilisation spécifiques :
- Neon excelle pour les applications serverless de nouvelle génération et les workflows de développement qui bénéficient du branching instantané et de la réduction des coûts grâce à la mise à l'échelle à zéro.
- Supabase présente un BaaS complet convaincant, tirant parti de PostgreSQL à son cœur et l'enrichissant de puissantes capacités en temps réel et de Edge Functions flexibles.
- PlanetScale a fait une forte entrée sur le marché PostgreSQL avec ses clusters
Metalhaute performance et le projet de fragmentation ambitieuxNeki.
Pour un développeur senior évaluant ces options, le choix dépend de la prévisibilité de la charge de travail, de l'importance du branching de type Git et de la nécessité d'un BaaS complet ou principalement d'une base de données avec des fonctionnalités de mise à l'échelle avancées. L'innovation continue, en particulier autour de la désagrégation architecturale et de l'expérience développeur, indique un avenir prometteur pour les bases de données relationnelles hautement évolutives et résilientes dans le cloud.
Sources
🛠️ Outils connexes
Explorez ces outils DataFormatHub liés à ce sujet :
- CSV vers SQL - Importer des données dans des bases de données
- JSON vers CSV - Exporter les résultats des requêtes