Hologres instances are sized in Compute Unit (CU) increments. Because Hologres uses a compute-storage separation architecture, storage scales independently—choosing an instance spec is really about selecting the right compute capacity for your workload.
This page explains how CU count maps to connections, shard counts, and query performance, so you can pick a starting spec and know when to adjust it.
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.
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.
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.
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.
For specs of 1,600 CUs or more: the frontend node count is capped at 100.
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 |
| 1,008–1,584 CUs | 63–99 | 200 | 128 × number of compute nodes | 256 × number of compute nodes | 5 × number of compute nodes |
| 1,600–2,272 CUs | 100–142 | 200 | 12,800 (128 × 100) | 25,600 (256 × 100) | 500 (5 × 100) |
| 2,288–4,000 CUs | 143–250 | 240 | 12,800 (128 × 100) | 25,600 (256 × 100) | 500 (5 × 100) |
| 4,016–8,000 CUs | 251–500 | 320 | 12,800 (128 × 100) | 25,600 (256 × 100) | 500 (5 × 100) |
| 8,016–8,192 CUs | 501–512 | 400 | 12,800 (128 × 100) | 25,600 (256 × 100) | 500 (5 × 100) |
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