Upgrade auf automatische Skalierung

Lakebase Provisioned-Instanzen wurden auf Autoscaling aufgerüstet, wodurch Lakebase auf einer einzigen Autoscaling-Plattform vereint ist.

Hinweis

Das Upgrade der Lakebase Provisioned-Instanzen auf Autoscaling wurde im Juli 2026 abgeschlossen. Neue Lakebase-Instanzen werden nun als Autoscaling-Projekte erstellt. Die Provisioned UI bleibt bis zum 1. September 2026 verfügbar und bietet so Zeit, um auf die Lakebase Autoscaling UI umzusteigen. Diese Seite dient als Referenz für die Unterschiede zwischen Autoscaling und Provisioned.

Neue Instanzen werden als automatisch skalierende Projekte erstellt.

Wenn Sie eine neue Lakebase-Instanz erstellen, wird sie jetzt als Lakebase-Autocaling-Projekt erstellt und auf der Seite "Automatische Skalierung " in der Lakebase-App und nicht auf der Seite "Bereitgestellt" angezeigt. Vorhandene bereitgestellte Instanzen sind nicht betroffen und laufen weiterhin wie zuvor.

Auf der Seite " Automatische Skalierung " werden die neuen Projekte mit einem Informationssymbol gekennzeichnet.

Zeigen Sie mit der Maus auf das Symbol, um eine QuickInfo anzuzeigen, die erläutert, dass das Projekt mithilfe der Datenbankinstanz-API erstellt wurde und dass es sowohl Datenbankinstanz als auch Postgres-APIs unterstützt.

Datenbankinstanzprojekte auf der Seite

Was dies für Sie bedeutet

  • Erstellung von Lakebase-Instanzen. Jede neue Lakebase-Instanz wird als Lakebase-Autocaling-Projekt erstellt und auf der Seite "Autocaling " in der Lakebase-App angezeigt. Sie können diese Projekte sowohl mit der Datenbankinstanz-API als auch mit der Postgres-API verwalten.
  • Schaltfläche „Erstellen“ auf der Benutzeroberfläche. Die Schaltfläche "Erstellen" (einschließlich im Tab "Bereitgestellt") öffnet nun den Autoscaling-Projekterstellungsprozess.
  • Features für die automatische Skalierung. Neue Projekte erhalten Autoskalierungsfunktionen, darunter die automatische Skalierung der Rechenleistung, Scale-to-Zero (standardmäßig mit einem 24-stündigen Timeout bei Inaktivität aktiviert), Branching und die sofortige Wiederherstellung. Sie können auf diese Features über die Lakebase Autocaling UI und die Postgres-API zugreifen, wenn Sie bereit sind.
  • Vorhandene bereitgestellte Instanzen bleiben unverändert. Sie verbleiben auf der Seite Bereitgestellt auf der Benutzeroberfläche mit demselben Verhalten wie zuvor. Bereitgestellte Instanzen, Verbindungszeichenfolgen und APIs funktionieren weiterhin.
  • Ihre vorhandene Automatisierung funktioniert weiterhin. Vorhandene Automatisierungen funktionieren ohne Änderungen, aber neue Instanzen werden als automatischen Skalierungsprojekte erstellt.

APIs

Neue Instanzen, die über die Datenbankinstanz-API erstellt wurden, unterstützen beide APIs, sodass vorhandene Automatisierung ohne Änderung fortgesetzt wird.

Instanz oder Projekt Zu verwendende API
Neue Projekte, die über die Datenbankinstanz-API erstellt wurden Beide APIs. Sie können dasselbe Projekt mit beiden verwalten.
Projekte, die in der Autoscaling-Benutzeroberfläche oder mit der Postgres-API erstellt wurden Nur Die Postgres-API .
Vorhandene bereitgestellte Instanzen vor dem Upgrade auf die automatische Skalierung Nur Datenbankinstanz-API .
Vorhandene bereitgestellte Instanzen nach dem Upgrade auf die automatische Skalierung Beide APIs. Sie können dieselbe Instanz mit beiden verwalten.

Die Automatisierung bestehender DABs mit database_instances funktioniert weiterhin. Allerdings werden neue Instanzen, die von database_instances erstellt werden, als Projekte mit automatischer Skalierung erstellt. Für neue Lakebase-Arbeiten empfiehlt Azure Databricks stattdessen die Verwendung von postgres_projects. Siehe Bündelressourcen.

Unterschiede für neue Lakebase-Instanzen

Berechnungsgröße

Lakebase-Instanzen, die als Projekt zur automatischen Skalierung erstellt wurden, verwenden Autoscaling-Recheneinheiten (CUs) anstelle von Lakebase bereitgestellten Kapazitätseinheiten. Wenn Sie ein Projekt mithilfe der Datenbankinstanz-API erstellen, ordnet Lakebase Ihre gewählte Einheit für bereitgestellte Kapazität wie folgt einem Mindest- und Höchstbereich für die automatische Skalierung in CUs zu:

Hinweis

RAM pro Einheit: In Lakebase Provisioned verfügt eine Kapazitätseinheit über 16 GB RAM. In Lakebase Autoscaling verfügt ein CU über 2 GB RAM.

Bereitgestellte Kapazität Autoskalierung min. CU Autoskalierung max. CU
1 (16 GB) 4 (8 GB) 8 (16 GB)
2 (32 GB) 8 (16 GB) 16 (32 GB)
4 (64 GB) 16 (32 GB) 32 (64 GB)
8 (128 GB) 48 (96 GB) 64 (128 GB)

Wenn Ihre Automatisierung beispielsweise Lakebase-Instanzen mit Kapazität 1 erstellt, werden neue Lakebase-Autoscaling-Projekte mit min CU 4 und max CU 8-Einstellungen erstellt. Sie können min/max später mithilfe der Postgres-API oder in der Lakebase Autocaling UI ändern.

Hinweis

Alle neuen Instanzen, einschließlich derer, die mit der Datenbankinstanz-API erstellt wurden, werden auf der Automatischen Skalierungsplattform ausgeführt und verwenden die Preise für die automatische Skalierung von Lakebase. Bei der flexiblen Berechnung, die die Abrechnung mit fester Kapazität ersetzt, sehen die meisten Kunden eine Reduzierung der Berechnungskosten. Bestehende bereitgestellte Instanzen behalten ihre aktuelle Preisgestaltung bei, bis sie aktualisiert werden. Siehe Upgrade vorhandener bereitgestellter Instanzen zur automatischen Skalierung.

Auf Null skalieren

Der Lese-/Schreibendpunkt für neue Projekte hat standardmäßig die Skalierung auf null aktiviert mit einem 24-Stunden-Inaktivitäts-Timeout, sodass Ihre Compute-Ressourcen nach 24 Stunden Inaktivität automatisch ausgesetzt werden, um Kosten zu senken. Sie können das Timeout anpassen oder scale-to-zero deaktivieren, um die Berechnung immer auszuführen, in der Ui für die automatische Skalierung von Lakebase oder mithilfe der Postgres-API. Details finden Sie unter "Skalieren auf Null ".

Verlaufsfenster

Auf Lakebase Provisioned (Datenbankinstanzen) kann das Wiederherstellungsfenster bis zu 35 Tage eingerichtet werden. Bei Lakebase Autoscaling (neue Projekte) ist die Einstellung für das Verlaufszeitfenster auf maximal 30 Tage begrenzt.

PostgreSQL-Version

Neue Projekte, die über die Datenbankinstanz-API oder lakehouse/Provisioned UI erstellt wurden, verwenden PostgreSQL 16, abgestimmt auf Lakebase Provisioned. Dies bedeutet, dass die Automatisierung mithilfe der Datenbankinstanz-API Projekte mit derselben PostgreSQL-Version (16) wie zuvor erstellt. Der Standardwert für Projekte, die mit der Automatischen Skalierungs-UI oder der Postgres-API erstellt wurden, ist PostgreSQL 17.

Verbindungsdetails und Hostnamen

Verbindungsdetails für neue Projekte verwenden ein anderes Hostnamenformat als Lakebase Provisioned. Bereitgestellte Instanzen verwenden einen globalen Hostnamen (keine Region im Hostnamen). Neu erstellte Projekte verwenden einen regionalen Hostnamen (Region eingeschlossen). Sowohl Lese-Schreib- als auch Nur-Lese-Endpunkte verwenden das regionale Hostnamenformat für neue Projekte.

Bereitgestellt (globaler Hostname):

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

Automatische Skalierung (regionaler Hostname):

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

Der regionale Hostname enthält den Regionscode für Ihre Cloud und Region (z. B. us-east-1 auf AWS oder eastus auf Azure).

Von Bedeutung

Wenn Sie IP-Zulassungslisten verwenden, müssen Sie die regionalen Eingangs-IPs für Ihre Region für neue Projekte zulassen. Siehe Erstellen von IP-Zugriffslisten für Arbeitsbereiche.

Lakebase Autoscaling verwendet zwei Private Link Endpunkte: front-end-Private Link für API-Zugriff (Konnektivität auf Arbeitsbereichsebene, unverändert) und inbound Private Link für leistungsintensive Dienste (inbound Private Link für leistungsintensive Dienste) für Postgres-Clientverbindungen. Ob Sie eingehende Private Link für leistungsintensive Dienste benötigen, hängt davon ab, wie Ihre Anwendungen eine Verbindung herstellen.

Ihre Situation Was Sie benötigen
Sie verwenden Private Link, erstellen eine neue Instanz und stellen mithilfe eines Postgres-Clients eine Verbindung von außerhalb des Azure Databricks Arbeitsbereichs her Fügen Sie inbound-Private Link für leistungsintensive Dienste hinzu.
Sie verwenden bereits Lakebase-Autoskalierung oder andere Dienste, die eingehenden Private Link für leistungsintensive Dienste nutzen. Keine Änderung.
Sie verwenden nur vorhandene bereitgestellte Instanzen und erstellen keine neuen Instanzen. Keine Änderung.

Berechtigungen (ACLs)

Berechtigungen für neue Lakebase-Instanzen werden in der Lakebase-Projekt-ACL-Ressource gespeichert. Sie können sie über die Standardberechtigungs-API mit request_object_type=database-projects, der Lakebase-Benutzeroberfläche für die automatische Skalierung oder der Postgres-API verwalten. Vorhandene Automatisierung, die die Datenbankinstanz-API verwendet, funktioniert weiterhin, da diese Aufrufe an dieselbe database-projects Ressource angefügt sind. Lese- und Schreibvorgänge bleiben auf beiden API-Oberflächen konsistent.

Früheres Berechtigungsmodell

Lakebase-Projekte, die mit der Datenbankinstanz-API oder verwandten Tools (CLI, SDKs, Terraform, DABs) zwischen dem 12. März und dem 11. Mai 2026 erstellt wurden, verwendet ein früheres Berechtigungsmodell, bei dem zwei unabhängige ACL-Sätze angewendet wurden:

  • ACLs der Datenbankinstanz: Werden über die Datenbankinstanz-API festgelegt und ausgewertet.
  • ACLs des Lakebase-Projekts: Werden über die Lakebase-Autoscaling-Benutzeroberfläche oder die Postgres API festgelegt und ausgewertet.

Die beiden Gruppen können verschiedene Zugriffsebenen gewähren. Überprüfen Sie sowohl die Datenbankinstanz als auch die Lakebase-Projekt-ACL-Sätze , um die effektiven Berechtigungen zu verstehen. Azure Databricks plant, Berechtigungen für diese Instanzen in einem zukünftigen Update zu vereinheitlichen.

Projektnamen und Instanznamen

Wenn Sie eine Lakebase-Instanz über die Datenbankinstanz-API oder die Lakehouse/Provisioned UI erstellen, wird der angegebene Instanzname zur Projekt-ID (project_id) des resultierenden Lakebase-Autocaling-Projekts. Der Stammzweig wird immer mit der ID productionerstellt.

Instanznamen und Projekt-IDs müssen DNS-kompatibel sein. Die Eindeutigkeit von Projekt-IDs ist unabhängig von der Groß-/Kleinschreibung, was bedeutet, dass Sie nicht sowohl ABC als auch abc als Projekt-IDs im selben Arbeitsbereich haben können. Verwenden Sie bei Verwendung der Postgres-API die Projekt-ID in Kleinbuchstaben. Die Erstellung schlägt fehl, wenn die Projekt-ID mit einer vorhandenen Projekt-ID kollidiert.

Projekte haben auch einen Anzeigenamen (display_name), der unabhängig von der Projekt-ID ist und nicht der DNS-Complianceanforderung unterliegt.

In der Postgres-API wird die Projektressource name im Pfadformat projects/{project_id} (zum Beispiel projects/my-instance) zurückgegeben und nicht als bloßer Instanzname, wie er von der Datenbankinstanz-API verwendet wird. Siehe "Projekte auflisten".

Umbenennung von Branch und Projekt

Wie Instanznamen können Projekt-IDs und Verzweigungs-IDs nach der Erstellung nicht mehr geändert werden. Projekte haben jedoch auch einen Anzeigenamen (display_name), den Sie jederzeit aktualisieren können.

Untergeordnete Datenbankinstanzen

Für untergeordnete Datenbankinstanzen (eine untergeordnete Instanz entspricht einer Verzweigung im Automatischen Skalierungsprojekt):

  • Branch-ID. Der Name der untergeordneten Instanz, den Sie in der Datenbankinstanz-API angeben, wird in der Benutzeroberfläche für die automatische Skalierung als Branch-ID verwendet.
  • Branch-Limit. Mit der Postgres-API oder der Benutzeroberfläche für die automatische Skalierung können Sie eine beliebige Anzahl von Verzweigungen erstellen. Mit der Datenbankinstanz-API können Sie nur eine übergeordnete Instanz (eine Stamm-Verzweigung) und eine untergeordnete Instanz (eine untergeordnete Verzweigung) erstellen, die dem vorherigen Verhalten der Datenbankinstanz-API entspricht.
  • Etiketten und Budget. Benutzerdefinierte Tags und Verwendungsrichtlinien werden vom übergeordneten Branch geerbt. Dies ist eine Änderung des vorherigen Api-Verhaltens der Datenbankinstanz , bei der untergeordnete Instanzen eigene separate Werte hatten.
  • Löschen einer untergeordneten Instanz. Wenn Sie zusätzliche Zweige mithilfe der Lakebase Autoscaling UI oder der Postgres-API für ein Projekt erstellen, das einer untergeordneten Instanz entspricht, können Sie diese untergeordnete Instanz erst über die Lakehouse/Provisioned UI oder API löschen, wenn alle diese Zweige gelöscht werden. Löschen Sie zuerst die Verzweigungen (mithilfe der API für die automatische Skalierung oder die Postgres-API), und löschen Sie dann die untergeordnete Instanz.

Geschützte Zweige

Wenn Sie eine Verzweigung für ein Projekt schützen, das mit der Datenbankinstanz-API erstellt wurde (unabhängig davon, ob die Verzweigung einer untergeordneten Instanz oder einer anderen von Ihnen erstellten Verzweigung entspricht), können Sie diese untergeordnete Instanz oder die Stamminstanz (übergeordnete Instanz) nicht über die Lakehouse/Provisioned UI oder API löschen, bis die Verzweigung nicht geschützt ist. Heben Sie zuerst den Schutz der Verzweigung in der Lakebase-Benutzeroberfläche für die automatische Skalierung auf, und löschen Sie dann die Instanz. Siehe geschützte Branches.

Private Vorschaufunktionen

Neu erstellte Projekte sind Lakebase Autoscaling-Projekte und unterstützen nicht die Lakebase Provisioned Data API oder Forward ETL als private Vorschaufunktionen. Dies waren separate Angebote unter „Bereitgestellt“.

  • REST-API-Zugriff (PostgREST-Style): Lakebase Autoscaling verfügt über eine eigene Daten-API für postgREST-kompatiblen REST-Zugriff (CRUD, Query, RPC).
  • Synchronisieren von Daten mit dem Lakehouse: Lakebase Autoscaling hat Lakebase Change Data Feed, der sich von der privaten Vorschau Forward ETL auf Lakebase Provisioned unterscheidet.

Upgrade vorhandener bereitgestellter Instanzen auf automatische Skalierung

Azure Databricks hat alle von Lakebase Provisioned Instanzen auf die Lakebase Autoscaling-Plattform aktualisiert. Das Upgrade wurde im Juli 2026 abgeschlossen.

Das Upgrade erfolgt automatisch. Verbindungen werden während des Übergangs kurz neu gestartet. Ihre vorhandenen Verbindungszeichenfolgen, API-Aufrufe, deklarative Automatisierungsbündel und Terraform-Konfigurationen funktionieren weiterhin ohne Änderungen.

Hinweis

Das Upgrade ändert nur die Computeplattform, nicht Ihre Daten. Alle Datenbankobjekte bleiben erhalten: Schemas, Tabellen, Indizes, Primärschlüssel, Fremdschlüssel, Postgres-Rollen und Zuschüsse. DLT-Pipeline-IDs bleiben ebenfalls erhalten.

Nach dem Upgrade gelten die folgenden Änderungen:

  • Compute-Größenanpassung. Die bereitgestellte Kapazität Ihrer Instanz wird einem CU-Bereich (min./max.) für die Autoskalierung zugeordnet. Siehe Rechengröße für die Zuordnungstabelle. Sie können min/max CU nach dem Upgrade mithilfe der Lakebase Autocaling UI oder der Postgres-API ändern.

  • Beide UIs sind verfügbar. Ihre Instanzen können sowohl über die neue Benutzeroberfläche für die automatische Skalierung als auch über die vertraute bereitgestellte Benutzeroberfläche verwaltet werden, die bis zum 1. September 2026 verfügbar bleibt.

  • Projektname und Anzeigename. Das Upgrade behält Ihre Projekt-ID und UID bei. Der Anzeigename (display_name) erhält das Suffix (upgraded), sodass eine Instanz namens my-instance in der Autoscaling-Benutzeroberfläche und der my-instance (upgraded) als angezeigt wird. Die aktualisierte Instanz wird sowohl in der Datenbankinstanz-API als auch in der Postgres-API mit der gleichen UID angezeigt.

  • Neue regionale Verbindungszeichenfolge. Jede Instanz erhält eine neue regionale Verbindungszeichenfolge mit optimiertem Eingang. Ihre vorhandene globale Verbindungszeichenfolge ist in der Bereitstellungs-UI verfügbar; Ihre neue regionale Verbindungszeichenfolge ist in der UI für automatische Skalierung verfügbar.

    • Vorhandene Verbindungszeichenfolgen. Bereitgestellte Verbindungszeichenfolgen (ohne Regionsangabe) funktionieren weiterhin über bestehende eingehende Private Links und erfordern keinen Service Direct Private Link.
    • Neue regionale Verbindungszeichenfolge. Wenn Sie Private Link verwenden und von außerhalb des Azure Databricks-Arbeitsbereichs eine Verbindung mit Lakebase herstellen, müssen Sie den eingehenden Private Link für leistungsintensive Dienste konfigurieren, um die neue regionale Verbindungszeichenfolge zu verwenden.
  • DABs und Terraform. Um neue Autoskalierungsfunktionen wie Scale-to-zero zu verwenden, aktualisieren Sie Ihre Bundles für die Verwendung von postgres_projects (siehe Bundle-Ressourcen) oder Ihre Terraform-Konfiguration für die Verwendung der Ressource databricks_postgres_project. Schritt-für-Schritt-Anleitungen für Terraform finden Sie unter Aktualisieren Sie Ihre Terraform-Konfiguration für die Verwendung von Autoscaling-Ressourcen.

  • Weitergeleitetes ETL (private Vorschau). Das Feature „Forward ETL“ der privaten Vorschau auf Lakebase Provisioned wird nicht mehr unterstützt und wird mit einem zukünftigen Update nicht mehr verfügbar sein. Um die Synchronisierung von Daten nach dem Upgrade mit dem Lakehouse fortzusetzen, richten Sie den Lakebase Change Data Feed auf der Automatischen Skalierungsplattform ein.

  • REST-API, PostgREST (private Vorschau). Das private Vorschaufeature der REST-API (PostgREST) auf Lakebase Provisioned funktioniert nach dem Upgrade weiterhin, wird aber nicht mehr unterstützt und wird in einem zukünftigen Update nicht mehr verfügbar sein. Der Ersatz, die Daten-API, ist auf der Automatischen Skalierungsplattform verfügbar.

  • Hochverfügbarkeit. Wenn hohe Verfügbarkeit in Ihrer bereitgestellten Instanz aktiviert wurde, wird sie nach dem Upgrade beibehalten.

  • Automatische Skalierungsverbesserungen. Deine Instanzen unterstützen automatische Skalierungsfunktionen. Lakebase Autoscaling fügt automatische Skalierung, Skalierung bis Null, Punkt-in-Zeit-Wiederherstellung, Momentaufnahmen, Wartungsfensterplanung, Datenbankverzweigung und andere Verbesserungen hinzu. Weitere Informationen finden Sie unter Lakebase Autoscaling.

    Hinweis

    Für aktualisierte Instanzen ist "Scale-to-Zero" standardmäßig nicht aktiviert . Im Gegensatz zu neuen Instanzen, bei denen Scale-to-Zero standardmäßig mit einem Timeout nach 24 Stunden Inaktivität aktiviert ist, müssen Sie Scale-to-Zero für aktualisierte Instanzen manuell aktivieren. Siehe Skalierung auf Null.

  • Optimiertes Speicher-Caching. Nach dem Upgrade priorisiert Lakebase Daten für den Stammbranch Ihres Projekts im Speichercache und optimiert so die Abfragelatenz. Sie können eine andere Verzweigung nach dem Upgrade priorisieren, indem Sie sie als geschützte Verzweigung markieren.

  • Rollen und Datenbanken je Niederlassung. Lakebase Autoscaling hat eine Grenze von 500 Postgres-Rollen und 500 Datenbanken pro Zweig. Lakebase Provisioned hatte keine solche Grenze. Das Upgrade wird normalerweise für Instanzen abgeschlossen, die diese Grenzwerte überschreiten, aber Sie können danach keine weiteren Rollen oder Datenbanken erstellen. Wenn Sie der Meinung sind, dass Ihre Instanz betroffen ist, wenden Sie sich an Ihr Kontoteam oder Azure Databricks Support.

  • Angehaltene Instanzen. Nach dem Upgrade gibt die Verbindung mit einer angehaltenen Instanz den Fehler zurück The endpoint has been disabled. Enable it using the API and retry. Um den Zugriff wiederherzustellen, aktivieren Sie die Compute-Ressource wieder, indem Sie update_mask=spec.disabled auf spec.disabled: false setzen. Siehe Deaktivieren oder Aktivieren eines Rechengeräts.

  • Preise. Lakebase GA-Preise gelten nach dem Upgrade. Bei der flexiblen Berechnung, die Instanzen mit fester Größe ersetzt, sehen die meisten Kunden eine Reduzierung der Berechnungskosten. Lakebase Autoscaling umfasst auch die Preise für dauerhaft verfügbare Rechenleistung. Aktuelle Preise finden Sie auf der Lakebase-Preisseite.

  • Featurespeicher und Modellbereitstellung. Databricks Online Feature Stores basieren auf Lakebase Autoscaling. Ihre vorhandenen Feature-Serving- und Model-Serving-Workloads funktionieren weiterhin, ohne dass Sie etwas tun müssen. Die create_online_store und update_online_store Schnittstellen müssen für Online-Shops, die Sie über den Feature-Engineering-Client verwalten, nicht geändert werden. Siehe Featurespeicher und Modellbereitstellung.

  • Databricks-Apps. Apps, die eine Lakebase-Ressource database verwenden, funktionieren nach dem Upgrade weiterhin. Verbindungsdetails, Umgebungsvariablen und Postgres-Rollen sind unverändert. Ändern Sie database in Ihrer App-Konfiguration nicht zu postgres. Dadurch wird eine neue Postgres-Rolle erstellt und der Zugriff auf vorhandene Daten unterbrochen. Verwenden Sie app.resources.postgresfür neue Apps . Siehe Hinzufügen einer Lakebase-Ressource zu einer Databricks-App.

  • Agenten für die Bereitstellung von Modellen Agents mit Lakebase-Verbindungen funktionieren nach dem Upgrade weiterhin. Azure Databricks empfiehlt die Migration von Agents zu Databricks-Apps, um die Vorteile der automatischen Skalierung zu nutzen. Siehe Migrieren eines Agents von Model Serving zu Databricks Apps.

Wenn Sie ein beschleunigtes Upgrade anfordern oder Fragen haben, wenden Sie sich an Ihr Kontoteam oder Azure Databricks Support.

Weitere Ressourcen