Qu'est-ce que PostgreSQL serverless ?

PostgreSQL (Postgres) serverless est un modèle de base de données cloud entièrement géré qui découple le calcul et le stockage. Cela permet à chacun de s'adapter indépendamment et automatiquement en fonction de la demande. Au lieu de gérer directement les serveurs de bases de données, les applications interagissent avec des systèmes qui provisionnent automatiquement les ressources de calcul en réponse à la charge de travail et les réduisent lorsqu'elles sont inactives.

Dans les environnements Postgres traditionnels, en revanche, les équipes doivent dimensionner l'infrastructure à l'avance, estimer les besoins en capacité et gérer la mise à l'échelle au fil du temps. Cela entraîne souvent un surprovisionnement, un gaspillage des coûts liés aux ressources inactives et des goulots d'étranglement des performances lorsque la demande dépasse la capacité disponible.

Le Serverless Postgres élimine une grande partie de cette surcharge en :

• Éliminant le provisionnement des serveurs et la gestion de l'infrastructure
• Supprimant le besoin de planification manuelle de la capacité
• Ne facturant que l'utilisation active plutôt que les ressources de calcul inactives

Le terme « serverless » peut être trompeur, car il ne signifie pas que les applications fonctionnent sans serveurs ni infrastructure. Les systèmes sous-jacents existent toujours, mais ils sont masqués par une couche d'abstraction et entièrement gérés par le fournisseur cloud. Les tâches telles que la configuration, la mise à l'échelle et la maintenance des serveurs sont en grande partie invisibles pour les utilisateurs et n'ont pas besoin d'être configurées ou gérées directement.

PostgreSQL traditionnel vs serverless

Les architectures PostgreSQL ont évolué au fil du temps, passant de modèles d'infrastructure provisionnés à des conceptions cloud-natives plus dynamiques.

Les déploiements Postgres traditionnels exécutent des ressources de calcul fixes en continu, quelle que soit la charge de travail. La mise à l'échelle nécessite une intervention manuelle ou des seuils préconfigurés, ce qui engendre des coûts permanents même lorsqu'une base de données est inactive.

Le Serverless Postgres a introduit un modèle différent. Les ressources de calcul sont provisionnées à la demande, s'adaptant automatiquement à l'activité de la charge de travail et se réduisant à zéro lorsqu'elles ne sont pas utilisées. La facturation est basée sur la consommation réelle plutôt que sur la capacité réservée.

Serverless Postgres peut également être utilisé aux côtés de plateformes de calcul serverless telles que Databricks SQL, permettant aux requêtes analytiques de s'exécuter indépendamment tout en accédant aux mêmes données sous-jacentes au sein d'une architecture lakehouse unifiée.

Cette transition est possible grâce à des changements architecturaux tels que le découplage des couches de stockage et l'orchestration du calcul à la demande, qui permettent aux ressources de s'adapter indépendamment et de répondre de manière dynamique à l'activité de la charge de travail.

Les principales différences sont les suivantes :

La prochaine évolution : l'architecture lakebase

À mesure que les architectures de bases de données évoluent, un troisième modèle émerge, qui s'appuie sur le serverless Postgres tout en répondant à ses limites. Cette approche est parfois appelée architecture lakebase.

Le Serverless Postgres améliore l'évolutivité et réduit la surcharge opérationnelle, mais il reste généralement séparé des systèmes analytiques. Cette séparation nécessite souvent le déplacement, la duplication ou la synchronisation des données entre les bases de données opérationnelles et les plateformes analytiques.

Les architectures lakebase changent notre façon de concevoir le stockage et le traitement des données. Elles combinent la puissance des bases de données transactionnelles avec la flexibilité d'une fondation lakehouse, créant ainsi une plateforme unique où les charges de travail opérationnelles et analytiques peuvent s'exécuter ensemble. Cela signifie qu'au lieu d'avoir des systèmes distincts pour différentes tâches, tout peut être fait sur une seule plateforme de données partagée. Le résultat est une réduction de la duplication des données et un moyen beaucoup plus simple d'accéder aux données et de les utiliser. En rassemblant tout, les architectures lakebase facilitent la gestion et l'analyse des données, ce qui peut conduire à une meilleure prise de décision et à des opérations plus efficaces.

Comment fonctionne l'architecture lakebase

Les architectures lakebase s'appuient sur les modèles de serverless Postgres tout en introduisant une intégration plus étroite avec le stockage cloud et les plateformes de données.

Les composants clés comprennent :

• Découplage du calcul et du stockage
  Le calcul est sans état (stateless) et s'adapte indépendamment, tandis que le stockage reste persistant et distribué.
• Calcul éphémère
  Les ressources de calcul démarrent pour traiter les requêtes et se réduisent lorsqu'elles sont inactives, ce qui permet une certaine élasticité sans maintenir d'infrastructure permanente.
• Systèmes de stockage basés sur les journaux (logs)
  Les modifications de données sont capturées sous forme de journal continu, qui peut être utilisé pour reconstruire l'état de la base de données et prendre en charge des fonctionnalités telles que la création de branches (branching), la récupération et l'accès temporel.
• Le stockage d'objets comme fondation
  Les données durables sont stockées dans un stockage d'objets cloud, ce qui permet l'évolutivité, la durabilité et l'alignement avec les architectures lakehouse.
• Plan de contrôle et orchestration
  Une couche de contrôle gère la mise à l'échelle, le routage et les événements du cycle de vie, en coordonnant dynamiquement le calcul et le stockage.

Pourquoi c'est important

En combinant des capacités transactionnelles et analytiques sur une fondation partagée, les architectures lakebase peuvent :

• Réduire ou éliminer la duplication des données entre les systèmes
• Permettre des analyses en temps quasi réel sur les données opérationnelles
• Simplifier l'architecture des données en consolidant l'infrastructure
• Prendre en charge les charges de travail émergentes, y compris les applications d'AI qui nécessitent un accès à la fois transactionnel et analytique

Cette transition reflète un passage de l'optimisation de systèmes individuels à leur unification au sein d'une architecture de données unique.

Comment fonctionne l'architecture serverless Postgres

Le Serverless Postgres repose sur une architecture cloud-native qui sépare le calcul et le stockage en couches indépendantes. Ce principe de conception fondamental améliore l'efficacité et la flexibilité en permettant à chaque composant de s'adapter indépendamment.

Une caractéristique clé de cette architecture est le comportement de mise à l'échelle à zéro (scale-to-zero). Lorsqu'aucune requête n'est en cours d'exécution, le système suspend automatiquement les ressources de calcul. Lorsqu'une nouvelle requête est émise, le calcul est réactivé. Cela introduit un court délai appelé latence de démarrage à froid (cold start), qui peut aller de quelques millisecondes à plusieurs secondes selon le fournisseur et la configuration.

Une autre capacité importante est la création de branches de base de données (branching), souvent implémentée à l'aide de techniques de copie sur écriture (copy-on-write). La création de branches permet aux équipes de créer des environnements de base de données isolés pour le développement, les tests ou la préproduction sans dupliquer les données. Les modifications apportées dans une branche n'affectent pas la base de données d'origine, ce qui permet une itération plus rapide et une expérimentation plus sûre.

Principaux fournisseurs de serverless Postgres

Les offres de serverless Postgres reflètent différentes étapes de l'évolution des bases de données provisionnées vers des architectures entièrement cloud-natives. Les premiers services gérés ont introduit la mise à l'échelle automatique au sein des architectures de bases de données existantes. Les conceptions cloud-natives plus récentes sont conçues pour prendre en charge les agents d'AI, les applications en temps réel et les charges de travail opérationnelles modernes. Ces systèmes découplent entièrement le calcul et le stockage et introduisent des capacités difficiles à obtenir avec les modèles antérieurs, telles que la mise à l'échelle rapide, la création de branches et une gestion plus flexible des ressources. Neon et Databricks Lakebase reposent sur cette fondation, conçue pour répondre aux exigences des applications axées sur l'AI et des systèmes basés sur des agents.

• Databricks Lakebase
  Une base de données opérationnelle construite sur l'architecture lakebase qui étend le serverless Postgres en intégrant des bases de données transactionnelles à une fondation lakehouse. Conçu pour répondre aux exigences des agents d'AI, des applications en temps réel et des charges de travail opérationnelles modernes, Databricks Lakebase permet aux charges de travail opérationnelles et analytiques de partager une plateforme de données commune. Les cas d'usage incluent le stockage de l'état des agents d'AI, l'alimentation d'applications transactionnelles et la fourniture d'insights analytiques directement dans les applications et les flux de travail. Le résultat est une réduction des mouvements de données et un accès plus cohérent d'un cas d'usage à l'autre.
• Amazon Aurora Serverless v2
  Un service géré compatible Postgres au sein d'AWS qui fournit une mise à l'échelle automatique (autoscaling) précise sans nécessiter de redémarrage de la base de données. Aurora Serverless v2 est conçu pour les charges de travail d'entreprise et s'intègre étroitement aux services AWS pour le réseau, la sécurité et la surveillance. Bien qu'il réduise la surcharge opérationnelle, le comportement de mise à l'échelle et l'isolation des ressources peuvent encore refléter les contraintes de l'infrastructure sous-jacente.

Pour les charges de travail d'analyse et de traitement de données, le calcul serverless est également disponible sur des plateformes telles que Databricks SQL. Bien qu'il ne s'agisse pas d'une base de données transactionnelle (OLTP), ces systèmes fournissent une exécution de requêtes serverless pour l'analyse et peuvent fonctionner aux côtés de systèmes basés sur Postgres.

Racines open source et options cloud-native

Postgres est un système de gestion de base de données relationnelle open source largement utilisé. Les offres Postgres serverless sont construites sur cette base et conservent une compatibilité totale avec l'écosystème Postgres plus large, qui comprend des extensions, des outils en ligne de commande tels que psql, des ORM courants et plus encore.

Les implémentations diffèrent selon la part du système sous-jacent qui est ouverte ou propriétaire. Certains fournisseurs, comme Neon, s'appuient sur une infrastructure open source et exposent davantage leur architecture à la communauté. D'autres, comme Amazon Aurora Serverless, sont des services gérés propriétaires qui masquent une grande partie de l'implémentation sous-jacente.

Quelle que soit l'approche, la plupart des solutions Postgres serverless visent à maintenir une compatibilité totale avec Postgres tout en ajoutant des fonctionnalités cloud-native telles que la mise à l'échelle automatique, le branchement de base de données et les opérations gérées.

Ces différences peuvent influencer le niveau de visibilité et de contrôle dont disposent les équipes sur les performances et les coûts. Les systèmes basés sur l'open source peuvent offrir une plus grande transparence et flexibilité, tandis que les services gérés propriétaires privilégient souvent la facilité d'utilisation et la simplicité opérationnelle.

Modèles de tarification et compromis de performance

Lors de l'évaluation de Postgres serverless pour des charges de travail de production, il est important de comprendre comment les modèles de tarification et les caractéristiques de performance influencent le coût, la latence et le comportement global du système.

Tarification basée sur l'utilisation : ce que vous payez réellement

La plupart des fournisseurs de Postgres serverless facturent selon trois dimensions principales :

• Calcul : généralement mesuré en fonction des ressources utilisées lors de l'exécution des requêtes, telles que le temps vCPU ou les secondes ACU
• Stockage : facturé en fonction de la quantité de données stockées, généralement en GB par mois
• Transfert de données : frais pour les données entrant et sortant de la base de données, selon la région et la configuration du réseau

Le calcul étant provisionné à la demande, les coûts s'adaptent à l'activité des charges de travail. Cela rend la tarification serverless particulièrement adaptée aux applications ayant un trafic variable ou imprévisible.

De nombreux fournisseurs proposent des offres gratuites utiles pour le développement, les tests et les charges de travail à petite échelle. Ces offres incluent généralement des limites sur l'utilisation du calcul, le stockage ou le temps d'exécution actif, ce qui les rend moins adaptées aux charges de travail de production ou aux applications à trafic soutenu.

Bien que la tarification serverless puisse être avantageuse pour les charges de travail variables, elle n'est pas toujours l'option la moins coûteuse. Dans le cas de charges de travail à fort trafic et continues, ou de requêtes à exécution longue, les coûts totaux peuvent dépasser ceux d'une instance de base de données provisionnée à capacité fixe.

Démarrages à froid, mise à l'échelle et fiabilité en production

L'une des principales considérations de performance avec Postgres serverless est la latence du démarrage à froid. Lorsqu'une base de données a été réduite à zéro, le calcul doit être réactivé avant que les requêtes puissent s'exécuter. Cela introduit un délai qui peut aller d'environ 100 millisecondes à plusieurs secondes selon le fournisseur et la configuration.

Plusieurs options d'atténuation peuvent réduire l'impact des démarrages à froid :

• Envoyer des pings périodiques de maintien en activité (« keep-alive ») pour éviter une suspension complète
• Configurer un seuil de calcul minimal pour maintenir les ressources partiellement actives
• Choisir des fournisseurs qui minimisent ou éliminent les démarrages à froid grâce à leur conception architecturale

Les systèmes serverless s'appuient également sur la mise à l'échelle automatique pour gérer l'évolution des charges de travail. Les ressources de calcul peuvent augmenter en réponse à un volume de requêtes accru et, dans certains cas, mettre à l'échelle les réplicas de lecture de manière indépendante pour prendre en charge les accès simultanés. Cette élasticité est particulièrement utile pour les applications sujettes à des pics de trafic imprévisibles.

Pour les charges de travail de production, la disponibilité et la tolérance aux pannes sont des considérations critiques. La plupart des fournisseurs de Postgres serverless gérés répliquent les données sur plusieurs zones de disponibilité et proposent des fonctionnalités intégrées de sauvegarde et de restauration. Cependant, les garanties de niveau de service et le comportement de restauration varient selon le fournisseur, il est donc important d'examiner et de vérifier la couverture SLA avant toute utilisation en production.

Des fonctionnalités telles que le comportement de démarrage à froid et la mise à l'échelle automatique rendent Postgres serverless bien adapté aux charges de travail à trafic variable, mais peuvent introduire des compromis pour les applications sensibles à la latence ou fonctionnant en continu.

Cas d'usage et limites de Postgres serverless

Postgres serverless et l'architecture lakebase répondent à des besoins de charge de travail différents. Comprendre quel modèle correspond à votre cas d'usage peut aider à éviter une complexité et des coûts inutiles.

Les directives suivantes peuvent vous aider à déterminer si Postgres serverless ou l'architecture lakebase est la solution la mieux adaptée à votre charge de travail.

Idéal pour Postgres serverless

• La plupart des charges de travail OLTP

Mieux adapté à l'architecture lakebase :

• Développement et déploiement d'agents d'AI
• Charges de travail variables ou par pics
• Environnements de développement, de test et de staging
• Startups cherchant à optimiser les coûts et à réduire la charge opérationnelle
• Applications serverless ou basées sur l'edge
• Flux de travail CI/CD avec création rapide d'environnements
• Applications SaaS multi-locataires (branchement et autoscaling)

Pour les charges de travail qui nécessitent des performances plus constantes ou une disponibilité continue, l'architecture lakebase répond à ces besoins en repensant la coordination du calcul et du stockage sur une plateforme de données partagée.

Comment démarrer avec Postgres serverless

Démarrer avec Postgres serverless implique généralement un processus de configuration simple :

1. Choisissez un fournisseur en fonction des exigences de vos charges de travail, de leur comportement de mise à l'échelle et de vos préférences en matière d'écosystème
2. Créez une instance de base de données via la console ou l'API du fournisseur
3. Configurez une chaîne de connexion avec les identifiants, la région et les paramètres d'accès
4. Connectez-vous à l'aide d'un client Postgres standard, d'un ORM ou de l'outil en ligne de commande psql

Bien que la configuration soit relativement simple, les premiers choix peuvent avoir un impact profond sur les performances globales et la durabilité. Les considérations liées au premier déploiement doivent inclure :

• Définir un niveau de calcul minimal si la latence du démarrage à froid est une préoccupation
• Configurer un gestionnaire de connexions (connection pooler) pour gérer les connexions simultanées dans des environnements serverless ou edge
• Activer les sauvegardes et la restauration à un instant dans le passé (point-in-time recovery) pour vous prémunir contre la perte de données
• Examiner les paramètres de mise à l'échelle et de délai d'expiration pour s'assurer qu'ils correspondent aux profils de trafic attendus

Postgres serverless peut être utilisé aux côtés de plateformes de calcul serverless telles que Databricks SQL pour l'analyse et l'ingénierie des données. Cette séparation permet aux requêtes analytiques de s'exécuter indépendamment du traitement transactionnel tout en fonctionnant sur les mêmes données sous-jacentes.

Pour les équipes qui gèrent des données opérationnelles aux côtés des analyses, les architectures émergentes telles que Databricks Lakebase étendent cette approche en unifiant les charges de travail transactionnelles et analytiques sur une plateforme de données partagée. Cela réduit les mouvements de données et simplifie l'accès aux données entre les systèmes.

L'architecture lakebase est-elle le Postgres serverless qu'il vous faut ?

Postgres serverless simplifie les opérations de base de données en éliminant une grande partie de la gestion de l'infrastructure et en alignant plus étroitement les coûts sur l'utilisation réelle. Le calcul et le stockage étant découplés, les ressources s'adaptent à la demande. Pour les équipes ayant des charges de travail plus exigeantes, l'architecture lakebase va encore plus loin sur cette base.

Ces compromis doivent être évalués avec soin. La prévisibilité des performances, le coût à grande échelle et des facteurs tels que la latence du démarrage à froid et la gestion des connexions varient selon la charge de travail.

Le choix du fournisseur est crucial. Les différences en matière de comportement de démarrage à froid, de modèles de tarification, de granularité de la mise à l'échelle et d'adéquation à l'écosystème peuvent avoir un impact significatif sur les résultats. Pour les charges de travail d'analyse et d'ingénierie de données, des plateformes telles que Databricks SQL offrent une exécution de requêtes serverless. Les équipes peuvent également découvrir comment ce modèle s'étend aux charges de travail opérationnelles grâce à la visite guidée du produit Databricks Lakebase.

Alors que les architectures de bases de données continuent d'évoluer, l'architecture lakebase unifie les charges de travail opérationnelles et analytiques sur un socle de données partagé.

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original