How does Lakebase scale-to-zero affect cold-start latency, open connections, and session state?

Summary

• Scale-to-zero suspends compute when idle but leaves all data safely in a durable storage layer, enabling fast recovery at lower cost than always-on systems.
• Databases reactivate in a few hundred milliseconds when you run a query, comparable in speed to a continuously running database.
• Open connections are terminated when compute scales to zero; applications must reconnect after resume. Use connection pooling with automatic reconnection.
• Session state (variables, temporary tables, connection context) does not survive scale-to-zero, but all committed database data, indexes, and schema are safely persisted in storage.

How does Lakebase scale-to-zero affect cold-start latency, open connections, and session state?

Scale-to-zero is one of Lakebase's most cost-effective features, but it requires understanding how it interacts with your application's connection patterns and state management. The key insight: Lakebase separates compute (which scales to zero) from durable storage (which remains active). This separation makes scale-to-zero fast and safe, but it has real implications for how you architect your application.

What is scale-to-zero?

When your Lakebase database is idle beyond a configurable timeout (adjustable between 60 seconds and 7 days, with 5 minutes as a recommended default), the compute layer automatically suspends. You pay nothing for compute while idle, only for the storage that keeps your data safe. When you run a query or a connection request arrives, the compute layer wakes up automatically and reattaches to your data.
This works because Lakebase disaggregates compute from storage. The compute layer is stateless: it contains no persistent data. All data lives in a durable storage layer (safekeepers, page servers, and cloud object storage) that remains active and reachable even when compute is paused.

Cold-start latency: how fast is recovery?

Resume time is fast. When a database scales to zero and compute is suspended, resuming is quick. Databases reactivate automatically within a few hundred milliseconds when you send a query. After a full cold start (compute fully down), transaction latency is comparable to a running database (no multi-second delay).
Compare this to traditional SQL warehouses, which require 30-60 seconds to resume from suspend. Lakebase achieves sub-second recovery because compute is stateless and simply attaches to existing storage. There is no data to move, no warm-up required. Lakebase maintains warm pools of minimal-resource Postgres instances (0.25 CPU/1GB RAM) that can start even faster for use cases where startup speed is critical.
You can configure the inactivity timeout between 60 seconds and 7 days. Shorter timeouts save more on idle costs; longer timeouts reduce the chance of unexpected cold starts during quiet periods.

Open connections after scale-to-zero

Connections are terminated when compute suspends. When scale-to-zero pauses the compute layer, any active database connections are terminated. Your application must re-establish its connection when it next issues a query.
This is different from a traditional database that keeps connections open. If your application holds a connection pool with persistent connections (the common pattern), those connections will be closed when scale-to-zero triggers. Upon resume, the pool reconnects automatically, and queries resume. Most modern connection pooling libraries (pgbouncer, SQLAlchemy with connection pooling, JDBC pools) handle this gracefully: they detect the closed connection and open a new one.
One caveat: applications that keep database connections open for very long periods without activity may experience brief connection interruptions (1-2 times per week in observed cases) even without scale-to-zero, due to infrastructure maintenance cycles. This is a known limitation as Lakebase and its underlying infrastructure evolve.

Session state: what is preserved, what is not

Database state is preserved. Session state is not. This is the critical distinction.
When compute scales to zero and then resumes:

• All committed data survives: Every transaction you committed before scale-to-zero remains safely in storage. Your tables, indexes, schema, and all data are intact after resume.
• All transactions are ACID-compliant: Committed transactions are durable; uncommitted work is rolled back if a connection is interrupted.
• Session-level state is lost: Connection-specific state does not survive. This includes temporary tables, session variables (like search_path or session-level settings), prepared statement handles, and any application-level context stored in the connection object itself.

For applications that need persistent context, store state in the database (committed rows) rather than connection-local variables. Session variables are lost on reconnect; database tables survive.

Design patterns for scale-to-zero

Pattern	How to implement
Use connection pooling with auto-reconnect	Most Postgres libraries (psycopg, SQLAlchemy, JDBC) detect closed connections and reopen automatically. No code change needed.
Store application state in the database	Use committed rows instead of connection-local variables. Session context survives across reconnects when stored as data.
Set inactivity timeout appropriately	Shorter timeouts save more idle costs; longer timeouts prevent surprise cold starts. Choose based on your workload pattern.
Enable prewarming if needed	For latency-critical workloads, Databricks offers scheduled prewarming: background tasks keep your database warm.

The key principle: your application should tolerate brief reconnections (a few hundred milliseconds) and store persistent state in the database, not in connection variables.

FAQs

Will my application's connection pool break when scale-to-zero suspends?

No, assuming your pool is configured to handle reconnection (the standard). The pool detects the closed connection, opens a new one, and queries resume. It's transparent to your application code.

Can I disable scale-to-zero?

Yes. You can set the inactivity timeout to very long periods (up to 7 days) or keep your database in always-on mode by adjusting compute settings.

What happens to prepared statements when scale-to-zero triggers?

Prepared statement handles are connection-level state and are lost on reconnect. Most query libraries (SQLAlchemy, Prisma, psycopg) re-prepare statements transparently on the new connection.

Is scale-to-zero suitable for production?

It depends on your workload. For applications with predictable traffic patterns or quiet overnight periods, scale-to-zero dramatically reduces costs. For high-frequency, always-on workloads, keeping compute provisioned (always-on) may be more appropriate.