What are the most important Lakebase limitations to test before a production deployment?

Summary

• Lakebase supports up to 16TB datasets with a maximum of 4,000 concurrent connections (1,000 for provisioned instances); test that your workload fits within these hard limits.
• Autoscaling compute ranges cannot exceed 16 compute units of difference; cold reads incur unpublished latency penalties, so validate your working set size fits in memory.
• Autovacuum, connection pooling, and low-level PostgreSQL tuning are not configurable; TimescaleDB and cross-database joins are unsupported; plan your schema and data sync strategy accordingly.
• Lakebase is optimized for OLTP workloads, not analytics; sync latency to the Lakehouse is in the 10-second range, and planned maintenance restarts occur roughly monthly.
• Before production, stress-test peak concurrent connections, cold read latency impact, autoscaling behavior under traffic spikes, and failover recovery times.

What are the most important Lakebase limitations to test before a production deployment?
Production readiness for Lakebase requires understanding its hard boundaries and operational constraints. The most critical limitations fall into five categories: dataset and concurrency scaling, compute flexibility, performance under cache misses, PostgreSQL configuration flexibility, and workload suitability. Testing against these limits is mandatory before going live.

Storage, concurrency, and compute boundaries

Lakebase supports a maximum dataset size of 16TB per instance, with autoscaling currently supporting up to 8TB of logical data. Larger deployments require splitting across projects, which is strongly discouraged. Maximum concurrent connections are 4,000 for autoscaling instances and 1,000 for provisioned instances. The product team is actively raising these ceilings, but concurrency is governed more by throughput (transactions per second, queries per second) than by connection count alone.
For compute scaling, autoscaling's range constraint is critical: the maximum difference between minimum and maximum compute cannot exceed 16 compute units. For example, you cannot configure autoscaling from 1 to 20 CU; a valid range would be 2 to 10 CU. Autoscaling evaluates resource usage every 5 seconds and completes scaling actions rapidly, typically in milliseconds.

Performance and latency under real-world access patterns

Lakebase's latency profile depends critically on working set size. Data that fits in your compute instance's local memory delivers millisecond-level latency. Cold reads that miss the cache and require fetching from object storage incur tail latency (particularly at p99) that the product team has not published, so you must test against your own workload.
Lakehouse Sync latency is important if you plan bidirectional data flows. Lakebase to Lakehouse achieves freshness in the 10-second range, while Lakehouse to Lakebase (Continuous Sync) has a minimum latency in the 15-second range. Only SCD Type 2 is supported for change-data-capture; Type 1 has no confirmed roadmap.

PostgreSQL configuration and extension constraints

Autovacuum, work_mem, shared_buffers, and connection pooling are not user-configurable in Lakebase. Low-level changes like ALTER SYSTEM are intentionally blocked. Databricks manages these settings for reliability at scale.
The TimescaleDB extension is unsupported due to licensing; use standard PostgreSQL partitioning instead. Cross-database joins are not natively supported; use Lakehouse Federation via Unity Catalog instead. WAL files are not accessible to customers; Databricks manages them internally.

Workload suitability

Lakebase is optimized for OLTP (online transactional processing). Do not use it for OLAP or analytical workloads; use Databricks SQL instead. Large-scale migrations from legacy proprietary relational databases are not recommended. Write-heavy NoSQL workloads are not suitable at scale.

Reliability and maintenance

Lakebase has defined SLO targets for single-zone and multi-zone high-availability deployments (specific targets differ; check current documentation). No formal SLA exists yet for Lakebase in Public Preview. Recovery times for unplanned failures vary: node hardware failure takes a few minutes, unhealthy nodes recover in seconds, and PostgreSQL crashes recover in under a minute. Planned maintenance restarts occur monthly; customer-specified maintenance windows are not yet supported.

Key capabilities to validate before production

Validation Area	What to Test	Why It Matters
Dataset size	Does your data fit in 16TB? Will you need multiple projects?	Splitting across projects has trade-offs to plan for
Concurrent connections	What is your peak connection count? Does it exceed 4,000 (1,000 for provisioned)?	Connections above your limit will fail; no queuing exists
Working set and latency	Does frequently accessed data fit in compute memory? What is acceptable p99 latency?	Cold reads incur unknown latency; test your access patterns
Autoscaling range	Can you define a range with ≤16 CU difference?	Invalid ranges prevent deployment
Sync latency	Is sync latency in the range of seconds (not milliseconds) acceptable?	Sync freshness expectations must align with your use case
PostgreSQL tuning	What parameters must you adjust? Can you live without them?	If you need TimescaleDB or custom work_mem, Lakebase is not suitable
Failover and recovery	What recovery time is acceptable?	Plan SLO accordingly

How Databricks approaches production validation

Review the Lakebase Fieldkit for comprehensive sizing and configuration guidance. Consult Lakebase documentation on autoscaling, concurrency management, and performance tuning. Before production, run load tests against your peak concurrent connections, peak query throughput, and expected data access patterns. Use multi-zone high-availability for demanding SLOs.

FAQs

Can I change Postgres parameters like work_mem or autovacuum settings?

No. Databricks manages these globally for stability. If your workload requires custom tuning, Lakebase may not be suitable; consider Databricks SQL for analytics or a self-managed PostgreSQL solution.

What happens if I exceed 4,000 concurrent connections?

Connections above your tier's limit will fail immediately. There is no queuing mechanism. Size your compute and connection pooling to stay below this limit under peak load.

Is cold-read latency published?

No. Databricks has not published p50, p95, or p99 latency for cache misses. Test your specific access patterns in a staging environment before production.

Can I use Lakebase for real-time analytics?

Lakebase is optimized for OLTP (transactional) workloads, not analytics. Use Databricks SQL for analytical queries. Lakebase works well for fast, consistent transactional access to datasets that fit in memory.