Choose the right Hologres instance specifications - Hologres

Key concepts

CU (Compute Unit) — The base resource unit for Hologres instances. Each 16 CUs corresponds to one compute node.

Shard — The unit of data partitioning within Hologres. Each shard handles read and write requests for a portion of data. Shards within the same Table Group distribute each table's data so that joins between co-located tables avoid cross-shard data movement (a *local join*). When data spans multiple shards, a redistribution operator shuffles it across the network—introducing scheduling overhead.

Table Group — A logical grouping that determines how shards are organized. All tables in the same Table Group share the same shard layout, enabling local joins between those tables.

Frontend node — The access layer that handles incoming connections. Total connections for an instance equal: maximum connections per frontend node × number of frontend nodes.

How shard count affects performance

Shard behavior differs by workload type:

Workload	Effect of more shards
Data writes and updates	Higher throughput — writes parallelize across shards
Point queries (with shard pruning)	Higher concurrency — each query hits one shard
OLAP (Online Analytical Processing) queries	Diminishing returns — multiple shards must coordinate, adding scheduling overhead
Row-oriented tables	Better read performance — natural distribution across shards

After scaling out an instance, more compute resources alone improve query concurrency. In most cases, leave the shard count unchanged unless you specifically need higher write throughput. If you scale out by less than five times the original size, do not adjust the shard count.

Important

The maximum number of connections cannot be modified. When an instance scales out or in, connection limits adjust automatically. However, the default shard count for existing databases does not change during scaling—update it manually if needed. New databases use the default shard count for the new spec.

When to adjust your spec

Before consulting the recommendation table, check whether your current spec is actually the bottleneck. The following signals indicate that a spec change is likely needed:

Signal	Likely action
Connection count is near or at the instance limit	Scale out (adds frontend nodes and raises connection ceiling)
Write throughput cannot keep up with ingest rate	Scale out, then increase shard count for existing databases
OLAP query latency is high but concurrency is low	Scale out for more compute nodes; do not increase shard count
Point query concurrency has plateaued	Scale out, then increase shard count if shard pruning is active

Run the following statement to check your current connection usage against the limit:

-- Returns the maximum connections for a single frontend node.
-- Multiply by the number of frontend nodes to get the instance total.
show max_connections;

If none of these signals are present, your current spec is likely sufficient.

Recommended specs by data volume

The right spec depends on more than row count alone. Access frequency, data access volume, compute workload (point queries vs. analytics), write throughput, and table count within a Table Group all factor in. Use the following table as a starting point.

Note

These recommendations are guidelines, not hard limits. A table with a small data volume can run on a high-shard instance; a large table can run on a single-shard instance. Match the shard count to your concurrency goal while keeping data concentrated enough to avoid unnecessary shuffle overhead.

Total data size	Recommended spec	Recommended shard count	Workload fit
Less than 40 million rows	32 cores or more	10–20	Development and testing. Not suitable for stress testing.
40 million–400 million rows	64 cores or more	20–40	Simple workloads: moderate write throughput, no mixed OLAP + point query concurrency.
400 million–4 billion rows	128 cores or more	40–80	Balanced writes and queries. Default starting point for production.
4 billion–40 billion rows	256 cores or more	80–240	High-throughput write or large-scale OLAP. Use multiple Table Groups; divide by business cohesion or data volume; specify the Table Group explicitly when creating tables.
40 billion–400 billion rows	512 cores or more	160–400	Very large-scale OLAP or multi-tenant workloads. Use multiple Table Groups (same guidance as above). Reserve high shard counts for very large tables only—standard tables do not benefit.

Default resources by instance spec

Since April 25, 2022, general-purpose instances support 512 CUs to 1,024 CUs. For higher specs, submit a ticket. Before upgrading to a larger spec, upgrade the instance to V1.1.58 or later.

Compute group instances support any spec from 32 CUs to 8,192 CUs without a ticket.

Note

Each 16 CUs corresponds to one compute node.
For specs of 512 CUs or less: the number of compute nodes equals the number of frontend nodes.
Total maximum connections = maximum connections per frontend node × number of frontend nodes. Values in parentheses show the per-node figure followed by the node count.

Instance spec	Compute nodes	Default shard count	Max connections (V2.1 and earlier)	Max connections (V2.2 and later)	Reserved connections for Superuser (V1.1 and later)
32 CUs	2	20	256 (128 × 2)	512 (256 × 2)	10 (5 × 2)
48–80 CUs	3–5	40	128 × number of compute nodes	256 × number of compute nodes	5 × number of compute nodes
96–112 CUs	6–7	60	128 × number of compute nodes	256 × number of compute nodes	5 × number of compute nodes
128–192 CUs	8–12	80	128 × number of compute nodes	256 × number of compute nodes	5 × number of compute nodes
208–352 CUs	13–22	120	128 × number of compute nodes	256 × number of compute nodes	5 × number of compute nodes
368–992 CUs	23–62	160	128 × number of compute nodes	256 × number of compute nodes	5 × number of compute nodes

What changes automatically when you scale

When you scale an instance out or in, the following changes happen automatically:

Configuration	Behavior during scaling
Maximum connections	Adjusted automatically to match the new spec
Default shard count (new databases)	Uses the default for the new spec
Default shard count (existing databases)	Does not change—update manually if needed

This means that after a scale-out, existing databases retain their original shard count. The additional compute nodes still improve query concurrency because more cores process each query. Update the shard count manually only if you need higher write throughput or plan to add significantly more data.

View and manage connections

Check the current connection limit

After connecting to a developer tool, run the following statement to see the maximum connections for a single frontend node:

-- View the maximum connections for a single frontend node.
-- Connections are balanced across all frontend nodes.
show max_connections;

Multiply the returned value by the number of frontend nodes to get the total instance connection limit.

Manage connections when the limit is reached

Each instance reserves connections for the Superuser role. When the connection limit is reached, a Superuser can connect and use SQL to view and release idle connections, or scale up the instance. For details, see Connections.

View and modify the shard count

Scaling out an instance does not change the shard count for existing databases—adjust it manually if your workload requires it. Increase the shard count when you need higher write throughput. For row-oriented tables, more shards also improve read performance due to natural data distribution.

For instructions, see Table Group and Shard Count user guide.

What's next

Table Group and Shard Count user guide — Create Table Groups and adjust shard counts
Connections — Monitor and release idle connections