Mise à niveau vers le dimensionnement automatique

Lakebase passe entièrement à l'Autoscaling.

• De nouvelles instances sont créées en tant que projets de dimensionnement automatique. Depuis le 12 mars 2026, les nouvelles instances Lakebase sont créées en tant que projets de mise à l’échelle automatique, et non comme des instances provisionnées.
• Mise à niveau des instances provisionnées existantes vers l'autoscaling. Les mises à niveau commencent en juin 2026 pour les clients qui en ont fait la demande, les mises à niveau d'instances restantes se poursuivant dans les semaines suivantes.

Les nouvelles instances sont créées en tant que projets Autoscaling

Lorsque vous créez une nouvelle instance Lakebase, elle est désormais créée en tant que projet de dimensionnement automatique Lakebase et apparaît sur la page Dimensionnement automatique de l'application Lakebase, et non sur la page Approvisionné . Les instances approvisionnées existantes ne sont pas affectées et continuent de fonctionner exactement comme avant.

Sur la page Autoscaling , les nouveaux projets sont marqués d'une icône d'information.

Passez la souris sur l’icône pour afficher une info-bulle expliquant que le projet a été créé à l’aide de l’API d’instance de base de données, et qu’il prend en charge les API d’instance de base de données et les API Postgres.

Ce que cela signifie pour vous

• Création d'instance Lakebase. Toute nouvelle instance Lakebase est créée en tant que projet de dimensionnement automatique Lakebase et apparaît sur la page Dimensionnement automatique dans l'application Lakebase. Vous pouvez gérer ces projets avec l'API d'instance de base de données et l'API Postgres.
• Bouton Créer dans l'interface utilisateur. Le bouton Créer (y compris dans l'onglet Provisioned) ouvre désormais le flux de création de projet Autoscaling.
• Fonctionnalités de dimensionnement automatique. Les nouveaux projets bénéficient de fonctionnalités de dimensionnement automatique, notamment le compute à dimensionnement automatique, la mise à l'échelle jusqu'à zéro (activée par default avec un délai d'inactivité de 24 heures), la création de branches et la restauration instantanée. Vous pouvez accéder à ces fonctionnalités à partir de l'interface utilisateur de Lakebase Autoscaling et de l'API Postgres lorsque vous êtes prêt. Pour une comparaison complète avec Provisioned, consultez le tableau Comparer les fonctionnalités.
• Les instances provisionnées existantes restent inchangées. Elles restent sur la page Provisioned dans l'UI avec le même comportement qu'auparavant. Les instances provisionnées, les chaînes de connexion et les APIs continuent toutes de fonctionner.
• Votre automatisation existante continue de fonctionner. Les automatisations existantes continuent de fonctionner sans modification, mais les nouvelles instances sont créées en tant que projets Autoscaling.

APIs

Les nouvelles instances créées via l'API d'instance de base de données prennent en charge les deux APIs, de sorte que l'automatisation existante se poursuit sans modification.

Instance ou projet	API à utiliser
Nouveaux projets créés via l'API d'instance de base de données	Les deux APIs. Vous pouvez gérer le même projet avec l'un ou l'autre.
Projets créés dans l'interface utilisateur Autoscaling ou avec l'API Postgres	API Postgres uniquement.
Instances provisionnées existantes avant la mise à niveau vers l'Autoscaling	API d'instance de base de données uniquement.
Instances provisionnées existantes après la mise à niveau vers l'Autoscaling	Les deux APIs. Vous pouvez gérer la même instance avec l'une ou l'autre.

Instance ou projet	API à utiliser
Nouveaux projets créés via l'API d'instance de base de données	Les deux APIs. Vous pouvez gérer le même projet avec l'un ou l'autre.
Projets créés dans l'interface utilisateur Autoscaling ou avec l'API Postgres	API Postgres uniquement.
Instances provisionnées existantes avant la mise à niveau vers l'Autoscaling	API d'instance de base de données uniquement.
Instances provisionnées existantes après la mise à niveau vers l'Autoscaling	Les deux APIs. Vous pouvez gérer la même instance avec l'une ou l'autre.

L'automatisation existante des DABs utilisant database_instances continue de fonctionner. Cependant, les nouvelles instances créées par database_instances sont créées en tant que projets d'autoscaling. Pour les nouveaux travaux Lakebase, Databricks recommande plutôt d'utiliser postgres_projects. Consultez les Ressources du bundle.

Différences pour les nouvelles instances Lakebase

Taille de compute

Les instances Lakebase créées en tant que projets Autoscaling utilisent des compute units (CU) Autoscaling au lieu d'unités de capacité provisionnées par Lakebase. Lorsque vous créez un projet à l'aide de l'API d'instance de base de données, Lakebase mappe votre unité de capacité provisionnée choisie à une plage d'UC de dimensionnement automatique minimale et maximale comme suit :

remarque

RAM par unité : dans Lakebase Provisionné, une unité de capacité dispose de 16 Go de RAM. Dans l'autoscaling Lakebase, une UC dispose de 2 Go de RAM.

Capacité provisionnée	CU minimum de dimensionnement automatique	Dimensionnement automatique max CU
1 (16 Go)	4 (8 Go)	8 (16 Go)
2 (32 Go)	8 (16 Go)	16 (32 Go)
4 (64 Go)	16 (32 Go)	32 (64 Go)
8 (128 Go)	48 (96 Go)	64 (128 Go)

Capacité provisionnée	CU minimum de dimensionnement automatique	Dimensionnement automatique max CU
1 (16 Go)	4 (8 Go)	8 (16 Go)
2 (32 Go)	8 (16 Go)	16 (32 Go)
4 (64 Go)	16 (32 Go)	32 (64 Go)
8 (128 Go)	48 (96 Go)	64 (128 Go)

Par exemple, si votre automatisation crée des instances Lakebase avec une capacité de 1 , de nouveaux projets d'autoscaling Lakebase sont créés avec les paramètres min CU 4 et max CU 8 . Vous pouvez modifier min/max plus tard en utilisant l'API Postgres ou dans l'interface utilisateur d'autoscaling de Lakebase.

remarque

Tarifs

Toutes les nouvelles instances, y compris celles créées à l’aide de l’API de l’instance de base de données, fonctionnent sur la plateforme Autoscaling et utilisent les tarifs Autoscaling de Lakebase. Avec le compute élastique remplaçant la facturation à capacité fixe, la plupart des clients constatent une réduction des coûts de compute. Les instances provisionnées existantes conservent leurs tarifs actuels jusqu'à leur mise à niveau. Voir Mise à niveau des instances provisionnées existantes vers l'autoscaling.

Monter en charge-to-zero

L'Endpoint de lecture/écriture pour les nouveaux projets a la **mise à l'échelle à zéro activée** par default avec un **délai d'inactivité de 24 heures**, de sorte que votre compute se suspend automatiquement après 24 heures d'inactivité pour réduire les coûts. Vous pouvez ajuster le délai d'expiration, ou désactiver la mise à l'échelle à zéro pour maintenir le compute toujours en cours d'exécution, dans l'interface utilisateur d'autoscaling de Lakebase ou en utilisant l'API Postgres. Voir Monter en charge pour plus de détails.

Fenêtre d'historique

Sur Lakebase Provisioned (instances de base de données), la fenêtre de restauration peut être configurée jusqu'à 35 jours . Sur Lakebase Autoscaling (nouveaux projets), le paramètre de la fenêtre d'historique a un maximum de 30 jours .

Version de PostgreSQL

Les nouveaux projets créés via l'API d'instance de base de données ou l'interface utilisateur Lakehouse/Provisionné utilisent **PostgreSQL 16**, alignés avec Lakebase Provisionné. Cela signifie que l'automatisation via l'API d'instance de base de données crée des projets avec la même version de PostgreSQL (16) qu'auparavant. La valeur par default pour les projets créés à l'aide de l'interface utilisateur d'Autoscaling ou de l' API Postgres est **PostgreSQL 17**.

Détails de connexion et Hostname

Les détails de connexion pour les nouveaux projets utilisent un format de Hostname différent de Lakebase Provisionné. Les instances provisionnées utilisent un Hostname global (pas de région dans le Hostname). Les projets nouvellement créés utilisent un Hostname régional (région incluse). Les Endpoints en lecture-écriture et en lecture seule utilisent le format de Hostname régional pour les nouveaux projets.

Provisionné (Hostname global) :

Text

host=instance-a1b2c3d4-e5f6-7890-abcd-ef1234567890.database.cloud.databricks.com

Autoscaling (hostname régional) :

Text

host=ep-example-endpoint-a1b2c3d4.database.<region>.cloud.databricks.com

Le Hostname régional comprend le code de région pour votre cloud et votre région (par exemple, us-east-1 sur AWS ou eastus sur Azure).

important

Si vous utilisez des listes d'autorisation IP, vous devez autoriser les adresses IP d'entrée régionales pour votre région pour les nouveaux projets. Voir Créer des listes d'accès IP pour les workspaces.

Private Link

Lakebase Autoscaling utilise deux endpoints Private Link : Private Link frontal pour l'accès à l'API (connectivité au niveau du workspace, inchangée) et Private Link entrant pour les services gourmands en performances (Private Link entrant pour les services gourmands en performances) pour les connexions client Postgres. Le fait que vous ayez besoin d'un Private Link entrant pour les services gourmands en performances dépend de la manière dont vos applications se connectent.

Votre situation	Ce dont vous avez besoin
Vous utilisez Private Link, créez une nouvelle instance et vous vous connectez depuis l'extérieur du workspace Databricks à l'aide d'un client Postgres	Ajouter Private Link entrant pour les services gourmands en performances.
Vous utilisez déjà l'Autoscaling Lakebase ou d'autres services qui utilisent un Private Link entrant pour les services gourmands en performances	Aucune modification.
Vous n'utilisez que les instances provisionnées existantes et n'en créez pas de nouvelles.	Aucune modification.

Votre situation	Ce dont vous avez besoin
Vous utilisez Private Link, créez une nouvelle instance et vous vous connectez depuis l'extérieur du workspace Databricks à l'aide d'un client Postgres	Ajouter Private Link entrant pour les services gourmands en performances.
Vous utilisez déjà l'Autoscaling Lakebase ou d'autres services qui utilisent un Private Link entrant pour les services gourmands en performances	Aucune modification.
Vous n'utilisez que les instances provisionnées existantes et n'en créez pas de nouvelles.	Aucune modification.

Autorisations (ACL)

Les permissions sur les nouvelles instances Lakebase sont stockées sur la ressource d'ACL de projet Lakebase. Vous pouvez les gérer via l'API de permissions standard avec request_object_type=database-projects, l'interface utilisateur d'Autoscaling Lakebase, ou l'API Postgres. L'automatisation existante qui utilise l'API d'instance de base de données continue de fonctionner car ces appels sont transmis à la même ressource database-projects. Les lectures et les écritures restent cohérentes sur les deux surfaces d'API.

Modèle d'autorisations antérieur

Les projets Lakebase créés avec l'API d'instance de base de données ou des outils connexes (CLI, SDK, Terraform, DAB) entre le 12 mars et le 11 mai 2026 utilisaient un modèle d'autorisations antérieur où deux ensembles d'ACL indépendants s'appliquaient :

• ACLs d'instance de base de données : définies et évaluées via l'API d'instance de base de données.
• ACLs de projet Lakebase : définies et évaluées via l'interface utilisateur de dimensionnement automatique Lakebase ou l'API Postgres.

Les deux ensembles peuvent accorder différents niveaux d'accès. Examinez à la fois les jeux d'ACL de l'instance de base de données et du projet Lakebase pour comprendre les autorisations effectives. Databricks prévoit d'unifier les autorisations sur ces instances dans une future mise à jour.

Noms de projet et noms d'instance

Lorsque vous créez une instance Lakebase via l'API d'instance de base de données ou l'interface utilisateur Lakehouse/Provisionnée, le nom d'instance que vous spécifiez devient l'ID de projet (project_id) du projet Lakebase Autoscaling résultant. La branch racine est toujours créée avec l'ID production.

Les noms d'instance et les ID de projet doivent être conformes au DNS . L'unicité de l'ID de projet est sensible à la casse , ce qui signifie que vous ne pouvez pas avoir à la fois ABC et abc comme ID de projet dans le même Workspace. Lorsque vous utilisez l'API Postgres, utilisez l'ID de projet en minuscules. La création échoue si l'ID du projet entre en conflit avec un ID de projet existant.

Les projets ont également un nom d'affichage (display_name), qui est indépendant de l'ID de projet et n'est pas soumis à l'exigence de conformité DNS.

Dans l' API Postgres, la ressource de projet name est renvoyée au format de chemin projects/{project_id} (par exemple, projects/my-instance), plutôt que le nom d'instance brut utilisé par l' API d'instance de base de données. Consulter la Liste des projets.

Renommage de la Branch et du projet

Comme les noms d'instance, les ID de projet et les ID de branch ne peuvent pas être modifiés après la création. Toutefois, les projets ont également un nom d’affichage (display_name) que vous pouvez mettre à jour à tout moment.

Instances de base de données enfants

Pour les instances de base de données enfants (une instance enfant correspond à une Branch sur le projet Autoscaling) :

• Branch ID. Le nom d'instance enfant que vous spécifiez dans l'API d'instance de base de données devient l'ID de Branch dans l'interface utilisateur d'auto-mise à l'échelle.
• Branch limit. Avec l'API Postgres ou l'interface utilisateur d'autoscaling, vous pouvez créer un nombre illimité de branches. Avec l'API d'instance de base de données, vous pouvez créer une seule instance parente (une root Branch) et une seule instance enfant (une child Branch), ce qui correspond au comportement précédent de l'API d'instance de base de données.
• Tags et budget. Les tags personnalisés et les politiques d'utilisation sont hérités de la Branch parente . Il s'agit d'un changement par rapport au comportement précédent de l'API d'instance de base de données, où les instances enfants avaient leurs propres valeurs distinctes.
• Suppression d'une instance enfant. Si vous créez des Branches supplémentaires à l'aide de l'interface utilisateur d'autoscaling Lakebase ou de l'API Postgres sur un projet qui correspond à une instance enfant, vous ne pouvez pas supprimer cette instance enfant via l'interface utilisateur ou l'API Lakehouse/Provisionnement tant que toutes ces Branches n'ont pas été supprimées. Supprimez d'abord les Branch (à l'aide de l'interface utilisateur Autoscaling ou de l'API Postgres), puis supprimez l'instance enfant.

Branch protégée

Si vous protégez une branch sur un projet créé à l’aide de l’ Database instance API (que la branch corresponde à une instance enfant ou à toute autre branch que vous avez créée), vous ne pouvez pas supprimer cette instance enfant ni l’instance racine (parente) via l’interface utilisateur ou l’API Lakehouse/Provisioned tant que la branch n’a pas été déprotégée. Commencez par retirer la protection de la branch dans l’interface utilisateur d’autoscaling Lakebase, puis supprimez l’instance. Voir les Branches protégées.

Fonctionnalités en aperçu privé

Les projets nouvellement créés sont des projets Lakebase Autoscaling et ne prennent pas en charge les fonctionnalités d'aperçu privé de l' API de données ou de l' ETL en amont de Lakebase provisionnée. C'étaient des offres distinctes sur Provisioned.

• **Accès à l'API REST (style PostgREST) :** Lakebase Autoscaling dispose de sa propre Data API pour un accès REST compatible PostgREST (CRUD, query, RPC).

• Synchronisation des données vers le Lakehouse : Lakebase Autoscaling dispose de Lakebase Change Data Feed, qui est différent de la préversion privée Forward ETL sur Lakebase Provisioned.

Mise à niveau des instances existantes provisionnées vers l'Autoscaling

Databricks met à niveau toutes les instances Lakebase provisionnées vers la plateforme Lakebase Autoscaling. Les mises à niveau débuteront en juin 2026 pour les clients qui les ont demandées, les mises à niveau d'instances restantes se poursuivant dans les semaines suivantes. Les administrateurs du Workspace reçoivent un e-mail avec les dates de mise à niveau avant le début de la mise à niveau.

La mise à niveau est automatique. Les connexions redémarrent brièvement pendant la transition. Vos chaînes de connexion existantes, appels d'API, Declarative Automation Bundles et configurations Terraform continuent de fonctionner sans modification.

remarque

La mise à niveau ne modifie que la plateforme compute, et non vos données. Tous les objets de base de données sont préservés : schémas, tables, index, clés primaires, clés étrangères, rôles Postgres et autorisations. Les ID de pipeline DLT sont également conservés.

Après la mise à niveau, les modifications suivantes s'appliquent :

• Dimensionnement du compute. La capacité de provisionnement de votre instance correspond à une plage CU min/max d'autoscaling. Consultez Taille du compute pour le tableau de correspondance. Vous pouvez modifier les CU min/max après la mise à niveau à l'aide de l'UI d'autoscaling Lakebase ou de l'API Postgres.

• **Les deux interfaces utilisateur sont disponibles.** Vos instances peuvent être gérées à la fois via la nouvelle interface utilisateur d'autoscaling et l'interface utilisateur provisionnée familière, qui reste disponible jusqu'au **1er septembre 2026**.

• Nom du projet et nom d'affichage. La mise à niveau préserve votre ID de projet et votre UID. Le nom d'affichage (display_name) reçoit un suffixe (upgraded). Ainsi, une instance nommée my-instance apparaît sous le nom de my-instance (upgraded) dans l'interface utilisateur d'Autoscaling et l'API Postgres. L'instance mise à niveau apparaît à la fois dans l'API d'instance de base de données et l'API Postgres, avec le même UID dans chacun.

• Nouvelle chaîne de connexion régionale. Chaque instance reçoit une nouvelle chaîne de connexion régionale avec une ingestion optimisée. Votre chaîne de connexion globale existante est disponible dans l'interface utilisateur Provisionnée ; votre nouvelle chaîne de connexion régionale est disponible dans l'interface utilisateur Autoscaling.

  • Chaînes de connexion existantes. Les chaînes de connexion provisionnées (sans région) continuent de fonctionner via l’Inbound PrivateLink existant et ne nécessitent pas Service Direct Private Link.
  • Nouvelle chaîne de connexion régionale. Si vous utilisez Private Link et vous connectez à Lakebase depuis l'extérieur du Workspace Databricks, vous devez configurer Private Link entrant pour les services à forte performance afin d'utiliser la nouvelle chaîne de connexion régionale.

• DABs et Terraform. Pour utiliser les nouvelles fonctionnalités de mise à l'échelle automatique, telles que la mise à l'échelle jusqu'à zéro, mettez à jour vos bundles pour utiliser postgres_projects (consultez les ressources du bundle) ou votre Terraform pour utiliser la ressource databricks_postgres_project. Pour obtenir des instructions détaillées sur Terraform, consultez l’article Mettre à jour votre configuration Terraform pour utiliser des Ressources de mise à l’échelle automatique.

• ETL anticipé (aperçu privé). La fonctionnalité d'aperçu privé Forward ETL sur Lakebase Provisioned n'est plus prise en charge et ne sera plus disponible lors d'une future mise à jour. Pour continuer à synchroniser les données avec le Lakehouse après la mise à niveau, configurez Lakebase Change Data Feed sur la plateforme d'autoscaling.

• API REST, PostgREST (aperçu privé). La fonctionnalité d’aperçu privé de l'API REST (PostgREST) sur Lakebase provisionné continue de fonctionner après la mise à niveau, mais n'est plus prise en charge et ne sera plus disponible dans une future mise à jour. Son remplacement, l'API de données, est disponible sur la plateforme Autoscaling.

• Haute disponibilité. Si la haute disponibilité était activée sur votre instance provisionnée, elle est conservée après la mise à niveau.

• Améliorations du dimensionnement automatique. Vos instances prennent en charge les fonctionnalités de dimensionnement automatique. Lakebase Autoscaling ajoute le dimensionnement automatique, la mise à l'échelle jusqu'à zéro, la restauration à un point dans le temps, les instantanés, la planification des fenêtres de maintenance, la création de branches de base de données et d'autres améliorations. Pour plus d'informations, consultez Lakebase Autoscaling.

remarque

La mise à l'échelle vers zéro n'est pas activée par default pour les instances mises à niveau. Contrairement aux nouvelles instances, pour lesquelles la mise à l'échelle vers zéro est activée par default avec un délai d'inactivité de 24 heures, les instances mises à niveau nécessitent que vous activiez manuellement la mise à l'échelle vers zéro. Voir Mettre à l'échelle à zéro.

• Mise en cache optimisée du stockage. Après la mise à niveau, Lakebase donne la priorité aux données pour la Branch racine de votre projet dans son cache de stockage, optimisant la latence des query. Vous pouvez prioriser une autre Branch après la mise à niveau en la marquant comme une Branch protégée.

• Rôles et bases de données par Branch. Lakebase Autoscaling a une limite de 500 rôles Postgres et 500 bases de données par Branch. Lakebase provisionnée n'avait pas une telle limite. La mise à niveau se termine normalement pour les instances qui dépassent ces limites, mais vous ne pouvez pas créer de rôles ou de bases de données supplémentaires par la suite. Si vous estimez que votre instance est affectée, contactez votre équipe de compte ou le support Databricks.

• Instances suspendues. Après la mise à niveau, la connexion à une instance suspendue renvoie l'erreur The endpoint has been disabled. Enable it using the API and retry. Pour restaurer l'accès, start l'instance à l'aide de l'interface utilisateur provisionnée ou de l'API des instances de base de données, ou définissez spec.disabled: false avec update_mask=spec.disabled à l'aide de l'API de mise à l'échelle automatique de Lakebase.

• Tarifs. Les tarifs de Lakebase GA s'appliquent après la mise à niveau. Avec le compute élastique remplaçant les instances à taille fixe, la plupart des clients constatent une réduction des coûts de compute. Lakebase Autoscaling comprend également les tarifs de compute toujours actif. Pour les tarifs actuels, consultez la page des Tarifs de Lakebase.

• Magasin de fonctionnalités et Model Serving. Les magasins de fonctionnalités en ligne Databricks sont basés sur l'Autoscaling de Lakebase. Vos charges de travail de Feature Serving et de service de modèles existantes continuent de fonctionner sans qu'aucune action ne soit requise. Les interfaces create_online_store et update_online_store ne nécessitent aucune modification pour les magasins en ligne que vous gérez via le client d'ingénierie de fonctionnalités. Voir Magasin de fonctionnalités et Model Serving.

• Databricks Apps. Les applications qui utilisent une ressource Lakebase database continuent de fonctionner après la mise à niveau. Les détails de connexion, les variables d'environnement et les rôles Postgres restent inchangés. Ne modifiez pas database en postgres dans votre configuration d'application. Cela crée un nouveau rôle Postgres et interrompt l'accès aux données existantes. Pour les nouvelles applications, utilisez app.resources.postgres. Voir Ajouter une Ressource Lakebase à une application Databricks.

• Agents d'IA sur Model Serving. Les agents dotés de connexions Lakebase continuent de fonctionner après la mise à niveau. Databricks recommande de migrer les agents vers Databricks Apps pour tirer parti des fonctionnalités d'autoscaling. Voir Migrer un agent de Model Serving vers Databricks Apps.

Pour demander une mise à niveau accélérée ou si vous avez des questions, contactez votre équipe de compte ou le support Databricks.

Ressources supplémentaires

• Lakebase
• Chaînes de connexion et À propos de l'authentification
• Créer un projet