Manage computes

A compute is a virtualized service that runs Postgres for your Lakebase projects. Each branch has one primary (read-write) compute. A compute is required to connect to a branch and access its data. For an overview of how computes and endpoints relate, see Computes and endpoints.

Understanding computes

Compute overview

Compute resources provide the processing power and memory needed to execute queries, manage connections, and handle database operations. Each project has a primary read-write compute for its default branch.

To connect to a database in a branch, you must use a compute associated with that branch. Larger computes consume more compute hours over the same period of active time than smaller computes.

Compute identifiers

Each compute has three identifiers, accessible from the Get ID menu on the Computes tab:

Identifier	Source	Example	Used in
Name	The endpoint ID, set to `primary` for the default compute. User-provided when creating endpoints through the API.	`primary`	API resource path (`.../endpoints/primary`)
UID	System-generated	`ep-sweet-butterfly-y2nm75e1`	Connection hostname
Resource name	Full API path	`projects/my-project/branches/production/endpoints/primary`	API calls

The hostname in your connection string uses the UID, not the compute name.

Compute sizing

Available compute sizes

Lakebase Postgres supports the following compute sizes:

Autoscale computes: 0.5 CU to 64 CU (0.5, then integer increments: 1, 2, 3... 64)
Larger fixed-size computes: 65 CU to 112 CU

Note

The Lakebase App displays a subset of commonly used sizes. Using the Postgres API, Terraform, Databricks Asset Bundles, or the Databricks SDK, you can set any integer CU value: 1–64 for autoscaling computes, and 65–112 for larger fixed-size computes.

What's in a Compute Unit?

Each Compute Unit (CU) allocates approximately 2 GB of RAM to the database instance, along with all associated CPU and local SSD resources. Scaling up increases these resources linearly. Postgres distributes the allocated memory across multiple components:

Database caches
Worker memory
Other processes with fixed memory requirements

Performance varies based on data size and query complexity. Before scaling, test and optimize queries. Storage scales automatically.

Note

Lakebase Provisioned vs Autoscaling: In Lakebase Provisioned, each Compute Unit allocated approximately 16 GB of RAM. In Lakebase Autoscaling, each CU allocates 2 GB of RAM. This change provides more granular scaling options and cost control.

Compute specifications

Compute Units	RAM	Max Connections
0.5 CU	~1 GB	105
1 CU	~2 GB	218
2 CU	~4 GB	443
3 CU	~6 GB	668
4 CU	~8 GB	894
5 CU	~10 GB	1119
6 CU	~12 GB	1344
7 CU	~14 GB	1570
8 CU	~16 GB	1795
9 CU	~18 GB	2020
10 CU	~20 GB	2246
12 CU	~24 GB	2696
14 CU	~28 GB	3147
16 CU	~32 GB	3597
24 CU	~48 GB	3993
28 CU	~56 GB	3993
32 CU	~64 GB	3993
36 CU	~72 GB	3993
40 CU	~80 GB	3993
44 CU	~88 GB	3993
48 CU	~96 GB	3993
52 CU	~104 GB	3993
56 CU	~112 GB	3993
60 CU	~120 GB	3993
64 CU	~128 GB	3993
72 CU	~144 GB	3993
80 CU	~160 GB	3993
88 CU	~176 GB	3993
96 CU	~192 GB	3993
104 CU	~208 GB	3993
112 CU	~224 GB	3993

Connection limits for autoscaling computes: When autoscaling is enabled, the maximum number of connections is determined by the smaller of your maximum CU and 8× your minimum CU. For example, if you configure autoscaling between 2-8 CU, your connection limit is 1,795 (the limit for 8 CU).

Read replica connection limits: Read replica compute connection limits are synchronized with your primary read-write compute settings. See Manage read replicas for details.

Note

Some connections are reserved for system and administrative use. For this reason, SHOW max_connections may show a higher value than the Max Connections shown in the table above or in the Edit compute drawer in the Lakebase App. The values in the table and drawer reflect the actual number of connections available for direct use, while SHOW max_connections includes reserved connections.

Sizing guidance

When selecting a compute size, consider these factors:

Factor	Recommendation
Query complexity	Complex analytical queries benefit from larger compute sizes
Concurrent connections	More connections require additional CPU and memory
Data volume	Larger datasets may need more memory for optimal performance
Response time	Critical applications may require larger computes for consistent performance

Optimal sizing strategy

Select a compute size based on your data requirements:

Full dataset in memory: Choose a compute size that can hold your entire dataset in memory for best performance
Working set in memory: For large datasets, ensure your frequently accessed data fits in memory
Connection limits: Select a size that supports your anticipated maximum concurrent connections

Autoscaling

Lakebase supports both fixed-size and autoscaling compute configurations. Autoscaling dynamically adjusts compute resources based on workload demand, optimizing both performance and cost.

Configuration Type	Description
Fixed size (0.5-64 CU)	Select a fixed compute size that doesn't scale with workload demand. Available for computes from 0.5 CU to 64 CU
Autoscaling (0.5-64 CU)	Use a slider to specify minimum and maximum compute sizes. Lakebase scales up and down within these boundaries based on current load. Available for computes up to 64 CU (128 GB)
Larger fixed-size computes (80-112 CU)	Select a larger fixed-size compute of up to 112 CU. These larger computes are available as fixed sizes only and do not support autoscaling

Autoscaling limit: Autoscaling is supported for computes up to 64 CU (128 GB). For workloads requiring more than 64 CU, larger fixed-size computes of 80, 96, or 112 CU are available.

Configuring autoscaling

To enable or adjust autoscaling for a compute, edit the compute and use the slider to set minimum and maximum compute sizes.

Autoscaling configuration

For an overview of how autoscaling works, see Autoscaling.