Lakebase & Operational Data

Lakebase is Databricks' fully managed Postgres database, integrated into the Databricks platform. Computes suspend when idle to minimize costs, instant branching creates isolated development and testing branches, and point-in-time restore creates a branch from a past moment within the restore window. Storing Postgres changes as Delta tables with full change history is in Public Preview, per the Lakebase docs.

The Lakebase change data feed writes Postgres changes to Delta tables with full change history, so downstream pipelines and analytics read current data without a separate ETL job. This capability is in Public Preview. Synced tables go the other way, copying Unity Catalog tables into Lakebase so applications can read them with low latency.

Databricks Lakebase is a fully managed, Postgres-compatible database built into the Databricks platform for operational and AI application workloads. It scales automatically, works with standard Postgres clients such as psql, and integrates with Unity Catalog. You can sync Unity Catalog tables into Lakebase so applications read lakehouse data with low latency.

Yes. Lakebase supports instant branching, so you can create an isolated branch of a database for development and testing. Branches can also be created from a point in your history window, and point-in-time branches let you query data as of a past time. Use branches to test schema or data changes without affecting production.

Yes. Lakebase is a fully managed Postgres database, and you connect with psql or any Postgres driver using standard Postgres clients and tools. Applications connect the same way they would to Postgres. Storing Postgres changes as Delta tables is in Public Preview, so check its status before relying on it.

Lakebase lets you sync Unity Catalog tables into Lakebase as synced tables, so applications can read lakehouse data with low latency. Sync modes are Snapshot, Triggered and Continuous. The sync pipeline owns the synced table's data, so applications should read it and keep their own writes in their own tables. This keeps operational applications working from the same governed data your lakehouse analytics use.

Agent Bricks agents can keep conversation state and long-term memory in managed stores backed by Lakebase, according to the Agent Bricks docs. The docs do not state a release status for agent memory or any benchmark results, so measure the effect on your own agent tasks.

Lakebase branches can be created instantly, regardless of database size, and share storage with their parent through pointers, writing new data only when it changes. You can create a branch from current data or from a past point in time to test schema changes safely. The 15-to-30-minute staging comparison in the Hamlet post is a customer account and is not verified.

A Databricks blog describes Lakebase bulk loads that offload work from the primary database to Spark, so loads do not compete with live traffic. The load-speed figures in the post are internal benchmarks and are not verified in the docs. The docs describe synced tables in Snapshot mode, which copies data once, and Triggered and Continuous modes for ongoing updates.

Lakebase branches are created instantly regardless of database size and share their parent's data through copy-on-write pointers, so each branch stores only its own changes. Branches are not merged back; schema changes move to the parent through standard migration tools, and a child branch can be reset to match its parent's current state. The per-worktree Git hook setup is from a Databricks blog example and is not docs-verified.

Agent memory lets agents recall what they learned in earlier conversations so they can personalize responses and reduce token costs. The docs say conversation state and long-term memory are kept in managed stores backed by Lakebase. The MemCurrent architecture and benchmark figures come from a Databricks research blog and are not in the docs.

A Databricks blog describes LTAP (lake transactional/analytical processing) as a planned design in which transactional and analytical workloads share one copy of the data in open Delta and Iceberg format. The Lakebase docs I checked do not describe LTAP, so see the docs for its current availability. Storing Postgres changes as Delta tables with full change history is in Public Preview, per the Lakebase docs.

Point-in-time restore creates a new root branch with your data as it existed at a selected moment within the restore window. The original branch is unchanged, and to use the restored data you point your application to the new branch. The restore window is configurable from 2 to 30 days, with a default of 7 days. The docs do not give restore durations.

Databricks Lakebase became generally available on February 3, 2026, on AWS (Azure was in beta at launch). It supports Postgres 16, 17 and 18, with Postgres 17 as the default and Postgres 18 selectable when a project is created. It includes pgvector for AI-driven search. Compute autoscales for heavy queries and traffic spikes and scales to zero when idle, so you are not billed for unused capacity. Instant branches of production data can be created in seconds, and point-in-time restore goes to a chosen point within a configurable 2-to-30-day window (default 7 days).

Lakebase Search adds vector search (lakebase_vector, a drop-in companion to pgvector with ANN indexes) and BM25 keyword search (lakebase_text) to Postgres, and hybrid search fuses both in one SQL query alongside filters and joins to live tables. The docs page does not state a release stage, and enabling Lakebase Search is irreversible once turned on. The sizing and AI Search comparison figures in the blog are not verified in the docs.

Lakebase Search provides approximate nearest-neighbor vector search (lakebase_vector), BM25 keyword search (lakebase_text) and hybrid search in one SQL query alongside filters and joins to live tables. The docs page does not state a release stage or the scale limits. The 100-million-vector benchmark and its recall and latency figures are vendor-reported and are not verified in the docs.

Zerobus Ingest writes event data directly into Unity Catalog Delta tables, through SDK, REST, OpenTelemetry, MQTT and Kafka-compatible interfaces. The docs page does not state a release stage for the whole service, and it gives no latency or throughput figures. The Lakebase sync latencies in the blog are not verified in the docs.

Consider search (vector, full-text and hybrid), serverless elasticity, Postgres compatibility, concurrency and latency, and governance with analytics integration. Lakebase is a fully managed Postgres database integrated into the Databricks platform, with compute that scales to zero when idle and Lakebase Search for vector and keyword search.

HTAP (hybrid transactional/analytical processing) runs analytics on current operational data without waiting for a batch pipeline. A Databricks blog describes LTAP as the Databricks approach to this, but the docs do not describe LTAP or its status. Storing Postgres changes as Delta tables with change history is in Public Preview, per the Lakebase docs.

Semantic caching stores question embeddings and returns a cached answer when a new question is similar enough. A Databricks community post implements this on Lakebase with pgvector and a similarity threshold. Lakebase's vector search is a drop-in companion to pgvector, per its docs. The threshold, hit-rate and latency figures in the post are community results and are not verified in the docs.

Lakebase is Databricks' Postgres database. The docs describe Autoscaling Lakebase databases that you select alongside a project and branch. Unity Catalog tables can be synced one way into Lakebase as synced tables in Snapshot, Triggered, or Continuous mode, and synced tables are generally available, so a sync step remains for that data. The docs describe LTAP Direct Writes, an optional synced-table setting that speeds up large loads, as in Beta.

Partly. Unity Catalog tables can be synced one way into Lakebase as read-only synced tables. The quickstart says 'a new read-only table appears in your Lakebase database', so a sync step still exists for that data. The sync-tables page states that synced tables are generally available and that LTAP Direct Writes, an optional synced-table setting that speeds up large loads, is in Beta. The cited docs do not describe a single-copy design, so do not plan around one.

Lakebase is a managed, Postgres-compatible database on Databricks, so applications keep their Postgres clients and drivers. Unity Catalog tables can be synced into Lakebase for low-latency reads, and Postgres changes can be stored as Delta tables for analytics (Public Preview). Lakebase branching lets you test migrations on an isolated copy of production data before applying them. The cited docs do not describe a specific incremental migration path from an existing Postgres or warehouse setup.

Lakebase is managed Postgres integrated with the Databricks lakehouse, with instant branching for development and testing, autoscaling compute that scales to zero when idle, and point-in-time restore. Access uses Databricks identity and authorization, and Lakebase can be registered as a read-only Unity Catalog catalog. Unity Catalog tables can be synced into Lakebase as synced tables, which is a sync step you configure and monitor. Comparisons with Neon or Aurora are not covered by the cited docs.

Lakebase runs OLTP on a Postgres engine, and Unity Catalog tables can be synced into it as synced tables in Snapshot, Triggered, or Continuous mode. Triggered and Continuous modes apply row-level changes incrementally and need a change data feed on the source; Snapshot copies all data on each sync. Synced tables are generally available. Lakebase databases also have branches, selected alongside the project and Postgres database.

Yes. Lakebase branches are created instantly, regardless of database size, and use copy-on-write so the branch shares its parent's data and stores only what changes. Each branch has its own compute that scales to zero when idle. Expiring branches bill only for the data written on them, while permanent branches pay for their full data size.

A Databricks blog reports internal benchmarks for loading large heap data into Lakebase Postgres in minutes, with index builds measured separately. These figures are not verified in the docs. For synced tables, the docs describe a one-time Snapshot copy and Triggered or Continuous modes for ongoing updates, and they do not give load-time figures.

Yes. Lakebase branches are created instantly and share parent data through copy-on-write, so each branch stores only its own changes. A child branch can be reset to its parent's current state. Branches are not merged back to main, and schema changes move through code and migrations. The per-worktree Git hook and PR CI workflow are from a Databricks blog example, not the docs.

Yes. A Lakebase branch can be created from production data so that migrations are tested against it before they reach the main database. The PR-level CI workflow and schema diff in the source blog are an example pattern and are not in the docs pages checked.

Yes, when each agent works on its own Lakebase branch. Branches share their parent's data through copy-on-write, so each agent's schema changes stay in its own branch. Idle branches scale to zero, and schema changes still reach main through code and migrations rather than branch merges.

Databricks Feature Store publishes features to the Online Feature Store, which is powered by Lakebase, and Model Serving looks up the latest feature values automatically at inference time. Feature tables are governed by Unity Catalog, which controls access and lets you view lineage of a feature table, model or function.

Lakebase is a fully managed Postgres database integrated into the Databricks platform, so applications run transactional workloads on it. Postgres changes can be stored as Delta tables with change history, which is in Public Preview per the Lakebase docs, so analytics can read current data without a separate ETL pipeline. Instant branches let you create isolated development and test environments from production.

Lakebase is a fully managed Postgres database integrated into the Databricks platform, with native Unity Catalog integration and sync of Unity Catalog tables into Lakebase. Whether it replaces Aurora or Cloud SQL depends on your requirements; the comparison is not from the docs.

Lakebase is a fully managed Postgres database integrated into Databricks, so you use standard Postgres clients and drivers without running database servers yourself. Unity Catalog tables can be synced into Lakebase so applications can query them at low latency. Self-managed PostgreSQL gives you full control, but you then handle operations and the wiring to analytics.

Lakebase is a fully managed Postgres database integrated into the Databricks platform, so operational applications get a Postgres database alongside the analytical platform. Unity Catalog provides governance and auditing for the platform's data and AI assets.

Lakeflow Connect's PostgreSQL database connector uses change data capture (CDC) to ingest source changes into Delta tables. A continuously running ingestion gateway captures changes before the source truncates its change logs, and a Unity Catalog volume stages the extracted data. An ingestion pipeline then applies those changes to destination streaming tables, which are Delta tables that support incremental processing.

Lakebase is a fully managed Postgres database integrated into the Databricks platform, built for low-latency transactional applications. It works with lakehouse data in both directions: Unity Catalog tables can be synced into Lakebase for fast application reads, and Postgres changes can be stored as Delta tables for downstream pipelines and audit history (Public Preview). Lakebase also includes autoscaling, scale to zero, instant branching, and high availability.

Lakebase is the transactional backend for Databricks Apps and external applications. It can also serve as the online feature store for Model Serving and a state store for agents. Lakehouse data reaches it through Unity Catalog synced tables, which Databricks strictly recommends reading with read-only queries. Keep application state in the application's own tables in the same database.

Lakebase branches are instant, copy-on-write copies of a database: a new branch starts from the parent's current data or from a past point in time, and it stores new data only when you change it. Every branch except the root branch has a parent, and changes on a child never affect the parent. The docs compare branching to Git conceptually, and branch reset works one way, from parent to child.

Add the Lakebase project, branch, and database as an app resource in the app's Configure step under App resources. Databricks creates a matching Postgres role for the app's service principal, so no manual role setup is needed, and it injects connection details as environment variables so no connection strings live in your code. The app server compute is sized separately from the Lakebase database compute, so each scales on its own.

In-region high availability gives automatic failover for compute and availability zone failures. Cross-region disaster recovery replicates project data to a Secondary Workspace in another region to protect against full region outages, and it is currently in Private Preview and not intended for production use during the preview. Failover is manual and replication is periodic, so the secondary may lag slightly, and the application switches to the new region's connection string.

Unity Catalog tables sync into Lakebase as synced tables, so applications can query lakehouse data with low latency. Sync modes are snapshot, triggered, and continuous, and continuous sync delivers changes with seconds of latency. Because the sync pipeline owns the synced table, Databricks recommends read-only queries on it, while applications store their own writes in their own tables.

Yes. Lakebase supports the pgvector extension (the vector data type with ivfflat and hnsw access methods) on Postgres 16, 17, and 18, so embeddings can live in the same database as transactional tables. Approximate nearest-neighbor vector search is provided by the lakebase_vector extension, which you enable after turning on Lakebase Search in project settings. Run pg_available_extensions to see every extension available in your database.

Yes. Embeddings are stored in a Postgres table with pgvector and queried with SQL alongside the rest of your application data. For approximate nearest-neighbor search, enable Lakebase Search and use the lakebase_vector extension. Check the extension table for the supported pgvector and lakebase_vector versions on your Postgres release.

Lakebase change data feed (Public Preview) stores Postgres changes as Delta tables with full history: every update becomes a new history row, and deletes are recorded as rows with _pg_change_type set to delete. This gives downstream pipelines and audit teams a complete trail while the Postgres database stays focused on current operational data. Setup is schema-level, so every current and future table in the source schema is included automatically once its replica identity is set to FULL.

Lakebase Postgres is a fully managed Postgres database integrated into the Databricks platform, so you can build applications right alongside your lakehouse data. It provides automatic scaling, instant branching, and Unity Catalog integration, so application data and lakehouse data can be used together. Its Unity Catalog integration lets you govern the lakehouse data your applications use.

Lakebase separates stateless Postgres compute from a durable, distributed storage layer, so data is kept in storage separate from compute. Behind each endpoint, one or more compute instances handle query processing. Synced tables and change data feed cover the two directions of that integration.

A new project comes with a single production branch and a default databricks_postgres database, so you can connect and start building right away. The production branch's compute has scale to zero enabled by default with a 24-hour inactivity timeout, so idle compute is suspended by default. To connect, select the production branch in the project and click Connect.

Lakebase Postgres Autoscaling supports Postgres 16, Postgres 17, and Postgres 18. Postgres 17 is the default, and you can select Postgres 18 when you create a new project. The version is selected when you create the project.

A Lakebase project is created in your Databricks workspace's region, so project data sits in the same region as the workspace. The docs give examples such as us-east-1 (US East, N. Virginia) and eu-west-1 (Europe, Ireland). Because the region is set to match the workspace and cannot be modified after creation, confirm your workspace region before you create a project.

Each project supports 20 concurrently active computes by default. The default branch is exempt from this limit so it stays available at all times, and the limit applies to other active computes in the project. The limit applies per project, so plan compute counts for each project.

Each branch supports up to 500 databases and up to 500 roles. Use these limits when planning how many databases and roles a single branch will hold. These per-branch limits apply to each branch you run, so size each branch separately.

You set minimum and maximum compute sizes, and Lakebase scales compute up when demand rises and down when activity falls, staying within that range. Each compute unit (CU) provides 2 GB of RAM, and the docs give an example of scaling between 2 and 8 CU. Scaling within the configured range happens automatically and does not require a restart.

Autoscaling is available for computes up to 64 CU (128 GB), and the spread between the maximum and minimum size can be up to 16 CU. Scaling within the range is automatic and needs no restart. Changing the minimum or maximum setting itself can briefly interrupt active connections, so schedule range changes with that in mind.

Scale to zero automatically suspends a compute after an inactivity timeout with no queries or connections. The timeout defaults to 24 hours and can be set between 60 seconds and 7 days. A suspended compute uses no resources and incurs no compute cost, while connection strings and credentials remain valid.

A suspended compute reactivates automatically within a few hundred milliseconds when a new query arrives, so no manual steps are needed. Because the session context resets on suspend and resume, including temporary tables, prepared statements, session settings, and active transactions, applications should plan to re-establish that state after reconnecting. Session-level settings should therefore be set again after a reconnect.

Scale to zero is available for computes of 32 CU or smaller. For autoscaling, it applies when the compute's maximum size is 32 CU or smaller, and enabling it on a larger compute returns an error. Compute above 32 CU must keep scale to zero disabled.

Yes, after you turn scale to zero off in the compute edit drawer. High availability then provisions secondary compute instances in different availability zones, so a compute or zone failure does not take the database offline. You can also configure high availability through the API using EndpointGroupSpec.

Lakebase provisions secondary compute instances in different availability zones, and once all compute instances are active the endpoint fails over automatically. A high availability endpoint runs 2, 3, or 4 total instances, made up of one primary and up to three secondaries. The endpoint's instance count is the one you configure, from 2 to 4 total.

Lakebase disaster recovery replicates a project's data into another region to protect against full region outages, and it is currently in Private Preview. Your workspace admin can request enablement by contacting your Databricks account representative. The docs state that it is not intended for production use during the preview.

Replication runs at the storage layer and periodically synchronizes data into a secondary region, whose compute stays idle until needed. Failover is controlled and always manual, and you can script it to automate the switch. Because replication is periodic, the secondary may be slightly behind the primary, and after failover the application connects using the new primary's connection string.

From the Computes tab on a branch, click Add Read Replica to provision a new read replica compute in seconds. Read replicas read from the same storage as the primary, so no data is duplicated or replicated. You can add up to 6 read replicas per branch.

Point-in-time restore lets you recover your data as it existed at a chosen moment. The restore window is configurable from 2 days up to 30 days, with a default of 7 days. To restore, select your source branch under Restore from history, choose a restore point with the date and time picker, and Lakebase creates a new root branch with that data.

A project supports up to 3 root branches, and each restore creates a new root branch. Delete root branches you no longer need to free a slot before your next restore. You may need to delete an unused root branch before the next restore.

Point-in-time branching creates a new branch with your data as it existed at the selected time, without affecting your production branch. The branch contains all databases and schemas as they existed at that moment, and you can query it within your configured restore window. Delete the branch when your analysis is done to avoid unnecessary storage usage.

Every branch except the root branch has a parent, and changes to a child branch never affect its parent. Lakebase uses copy-on-write, so a branch appears instantly regardless of database size and stores new data only when you modify it. When you create a branch, you choose whether to initialize it from current data or from a specific point in time.

An expiring branch is billed only for the data that changes on it, which suits short-lived copies for testing or analysis. A permanent branch is billed for its full data size, like an independent database. Choose the branch type based on how long you need the copy to live.

Synced tables offer three modes. Snapshot copies all data on each sync and needs only SELECT access on the source, Triggered runs on demand or at intervals, and Continuous streams changes in real time with seconds of latency and a 15-second minimum interval. Triggered and Continuous apply row-level changes incrementally.

Synced tables support managed and external Delta tables, managed and external Iceberg tables, and views and materialized views as sources. With Automatic change data feed, more source types, including Apache Iceberg tables, can sync in Triggered or Continuous mode. Complex ARRAY, MAP, and STRUCT types are stored as JSONB in Postgres.

Triggered and Continuous modes apply changes incrementally, so they use change data feed on the source. You can enable write-time change data feed on the source table, or turn on Automatic change data feed. Snapshot mode needs only SELECT access.

Primary key columns are non-nullable in the synced table. If the source has duplicate primary keys, configure a timeseries key to deduplicate them, which keeps the sync running. The primary key and timeseries key are set when you create the synced table and cannot be changed afterward.

In Catalog Explorer, open the table's details view, click Create, then choose Synced table, and set the destination, sync settings, pipeline settings and schema. You can also create synced tables with the Databricks CLI, the Python or Java SDK, or the REST API. The REST call returns a long-running operation, so poll it until done is true to confirm the table is ready.

A single source table can feed up to 20 synced tables, and each sync can use up to 16 connections to your Lakebase database. Databricks recommends keeping tables that require refreshes at or below 1 TB. Triggered and Continuous modes support additive schema changes such as adding columns.

The sync pipeline owns a synced table's data, so Databricks strictly recommends read-only queries on it to protect integrity with the source; direct writes are overwritten on the next refresh. Applications keep their operational state in their own tables in the same database, handling inserts, updates, and deletes there, and query the synced data alongside it. This keeps the synced data consistent with its source in Unity Catalog.

Lakebase change data feed (Public Preview) is configured at the schema level, so every current and future table in the source schema is included automatically. Each row-level change appears in a destination Delta table, and every update becomes a new history row for a complete audit trail. Deletes are recorded by appending a row with _pg_change_type set to delete.

Set the table's replica identity to FULL with ALTER TABLE ... REPLICA IDENTITY FULL, so Postgres writes full row data to the write-ahead log for each change. You also need CREATE TABLE permission on a Unity Catalog catalog and schema to receive the Delta tables.

Yes. pgvector is available under the extension name vector and provides the vector data type plus ivfflat and hnsw access methods, installed with CREATE EXTENSION vector. Supported versions are 0.8.0 on PG-16, 0.8.0 on PG-17, and 0.8.6 on PG-18.

Yes. PostGIS (extension name postgis) provides geometry and geography spatial types and functions, and you install it with CREATE EXTENSION postgis. CASCADE installs required dependencies automatically. Supported versions are 3.3.10 on PG-16, 3.5.7 on PG-17, and 3.6.4 on PG-18.

Supported extensions install with CREATE EXTENSION, and CASCADE installs their required dependencies. Lakebase updates supported extensions to newer versions over time; existing installations keep their current version until you run ALTER EXTENSION name UPDATE. Moving to a new extension version requires a compute restart, which you can plan for.

OAuth tokens expire after one hour, and expiration is enforced only at login, so an open session stays connected. To connect again, generate a new token and use it as the password. Tokens are generated on demand, so access is always backed by a current credential.

Yes. Native Postgres password authentication uses traditional Postgres roles, and their passwords do not expire automatically. Password connections are disabled by default for new Lakebase projects, so you turn them on deliberately when an application needs a static password role.

A service principal authenticates by minting OAuth tokens as itself. You configure the service principal with indefinitely lived credentials, and applications mint a fresh OAuth token when they connect. Because tokens expire after one hour, the application mints a new one when it reconnects.

Yes. A Postgres role is created automatically for your Databricks identity when you create a project. OAuth roles are linked to a user, a service principal, or a workspace-level group, while password roles use a static Postgres password and are not linked to a Databricks identity.

The default project role is a member of databricks_superuser, which gives it broad privileges to manage database objects. The databricks_superuser role inherits pg_read_all_data, pg_write_all_data, and pg_monitor. This membership is what gives the default project role its broad privileges.

Role names must be valid Postgres identifiers of up to 63 characters. Managing database roles requires the CAN MANAGE or CAN USE project permission, and a role that owns a database cannot be deleted. Grant CAN MANAGE or CAN USE only to people who need to manage roles.

Yes. Lakebase requires SSL/TLS for every connection, and sslmode=require is included in connection strings by default. For a Databricks identity, use a time-limited OAuth token as the password. The token expires one hour after it is generated, and expiry is enforced at login.

When you add Lakebase as an app resource, Databricks creates a matching Postgres role for the app's service principal with full database access. The resource injects connection details into the app as environment variables, so no connection strings appear in your code. Each Databricks app runs as its own service principal, separate from any individual user.

External applications can use the Databricks SDK for Python, Java, or Go, which handles workspace token rotation and takes explicit service principal credentials. Applications written in other languages, such as Node.js, Ruby, or PHP, use the REST API and manage token rotation themselves. Choose the route based on your language, since the SDK covers Python, Java, and Go.

Lakebase compute is billed for active hours, and computes scale to zero when idle, which the branches docs describe. For current rates, trial terms and committed-use options, check Databricks' Lakebase pricing page, since the docs I checked do not include pricing.

Yes. Registering a Lakebase database creates a read-only Unity Catalog catalog that mirrors its Postgres structure, so you can query Unity Catalog tables and Lakebase databases from one SQL interface. You need CREATE CATALOG privileges on the metastore, the registering user becomes the catalog owner, and serverless compute is used to query the catalog.

Each registered catalog represents one Lakebase database and is read-only, so it gives you a governed view of the data. Serverless compute is what you use to query these catalogs, and Pro and classic SQL warehouses and classic compute are not supported. A branched database cannot be registered as a separate catalog, so register the database itself.

Lakebase autoscaling computes range from 0.5 CU up to 64 CU, and the difference between the maximum and minimum compute sizes cannot exceed 16 CU. Each compute unit allocates approximately 2 GB of RAM to the database instance. You can also choose a fixed compute size instead of a min-max range.

Scale to zero suspends inactive computes to eliminate compute charges, and it is available for computes of 32 CU or smaller. The idle timeout can be set from 60 seconds to 7 days and defaults to 24 hours. When a new query or connection arrives at a suspended compute, Lakebase reactivates it automatically, and Databricks advises applications to include connection retry logic because wake-up takes a brief moment.

Lakebase branches use copy-on-write technology and Databricks says they are created in seconds. Only modified data is stored separately, which minimizes storage costs, and the docs describe creating branches without duplicating data. Each branch has its own compute and databases, so you can test on an isolated environment.

Snapshot copies all data with a full refresh each time it runs and needs only SELECT access. Triggered runs scheduled or on-demand updates that apply row-level changes incrementally, and Continuous provides real-time streaming with seconds of latency and a 15-second minimum interval. Triggered and Continuous need change data feed on the source, either write-time change data feed or Automatic change data feed, which computes row-level changes at read time.

Yes. Databricks describes Lakebase as a fully managed Postgres database integrated into the Databricks platform, and you can connect using standard Postgres clients and tools. It is designed for low-latency, real-time transactional applications that need to work alongside lakehouse data. Autoscaling adjusts compute to workload demand, and scale to zero suspends inactive computes.

Databricks says managed stores backed by Lakebase hold agent conversation state and long-term memory. This is part of the Agent Bricks platform, which also provides Agent Runtime and MLflow Tracing for observability. Because the memory store is backed by Lakebase, it uses the same Postgres-compatible database service described in the Lakebase docs.

The Lakebase connection pooler supports up to 10,000 concurrent client connections. Pooling lets many application clients connect through the pooler, which keeps client concurrency separate from the database's own connection limit. Choose a compute size that matches your workload before relying on pooled connections.

No. Connection pooling requires native Postgres password authentication and is not available for OAuth roles. If your application authenticates with OAuth, plan for direct connections and size compute for them. Native Postgres password roles are the path to pooled connections.

A branch can have up to 6 read replicas. Read replicas also count toward the project-wide limit of 20 concurrently active compute instances, so plan replica count against that project limit. Replicas let read-heavy Lakebase workloads scale out without changing the primary compute.

A workspace can hold up to 1,000 Lakebase projects according to the project limits table in the Databricks docs. Each project has a default limit of 20 concurrently active computes, and the default branch is exempt from that limit. Check the project limits page for current values before you size a deployment.

All Lakebase Provisioned instances were upgraded to the Lakebase Autoscaling platform, now known simply as Lakebase. The upgrade completed in July 2026. Databricks states it preserved your data, connection strings, API calls, and Asset Bundle and Terraform configurations, so existing integrations were carried over rather than rebuilt.

Yes, in Beta. ai_search can retrieve from Lakebase synced tables that have Lakebase Search enabled, either on their own or combined with Vector Search sources, up to 10 knowledge sources per call. Enabling Lakebase Search requires beta access and is irreversible, and it requires the lakebase_vector extension. The ai_search function reference describes the syntax.

For live, customer-facing application queries, Databricks offers Lakebase, a fully managed PostgreSQL database integrated into the platform, and applications connect with standard Postgres clients and drivers. You can sync Unity Catalog tables into Lakebase so applications can query them at low latency, while analytical data stays in the lakehouse. That split is the design: Lakebase serves live applications, and the lakehouse handles analytics and the surrounding data work. Whether this is cheaper than your current setup depends on your access pattern and data size, so benchmark a representative workload before you decide between a SQL warehouse, Lakebase, or a conventional database.