Hologres V2.0 introduces a virtual warehouse instance type that separates compute from shared storage, enabling read/write splitting, resource isolation, and service isolation within a single instance — without requiring multiple endpoints or cross-instance coordination.
Background
Hologres V1.1 uses a high availability (HA) deployment model for read/write splitting: a primary instance shares storage with one or more read-only replica instances while keeping compute resources isolated. For more information, see Primary/replica instance deployment for read/write splitting (shared storage).
This model has two key limitations:
-
Each instance requires a separate endpoint. Switching traffic means changing the endpoint.
-
Read-only replica instances share metadata with the primary instance, so you cannot set parameters per replica — for example, you cannot configure different replica counts for individual read-only instances to meet query HA requirements.
Hologres V2.0 addresses both limitations with virtual warehouse instances. A virtual warehouse instance divides its compute resources into independently scalable units called virtual warehouses (Leader and Follower). All virtual warehouses share data and metadata, and the instance exposes a single endpoint — no endpoint change is required when switching traffic.
Starting from Hologres V4.0, the virtual warehouse architecture is upgraded to support write-write isolation at the table group level, in addition to read/write and read/read isolation.
Limits and version notes
A virtual warehouse instance supports up to 10 virtual warehouses. The resource size of a single virtual warehouse starts from 32 CU.
Maximum size per virtual warehouse:
| Version | Maximum virtual warehouse size |
|---|---|
| V3.0.27 and later | No limit |
| V3.0.10–V3.0.26 | 1,024 CU |
| V2.0–V3.0.9 | 512 CU |
Read and write task assignments by version:
Hologres V2.0:
| Task type | Leader | Follower |
|---|---|---|
| Data query | Yes | Yes |
| Data write tasks | Yes | No |
Hologres V4.0 and later:
| Task type | Leader | Follower |
|---|---|---|
| Data query | Yes | Yes |
Batch data import (insert into select) |
Yes | Yes |
| Fixed Plan writes (Insert, Update, Fixed Copy) | Yes | No |
| Write-write isolation (table group level) | Yes | No |
Starting from Hologres V4.0, to enable Follower virtual warehouses to use local resources for batch data import tasks, enable the GUC parameter hg_warehouse_enable_use_local_resource. For more information, see GUC parameters reference.
To grant permissions to Leader and Follower virtual warehouses, see Authorize access to data in virtual warehouses.
Architecture
A virtual warehouse instance decouples compute from shared storage: virtual warehouses scale independently without affecting each other's performance, while all sharing the same underlying data and metadata.
V4.0 architecture
The V4.0 architecture is upgraded to provide ultimate write-write isolation for a single table group:
V2.0 architecture
-
Version 2.0 supports basic read/write and read/read fencing.
-
In V2.0, write-write isolation requires splitting data into multiple table groups at the storage layer. For more information, see Concepts.
The architecture comprises three layers:
-
Data storage: Built on Alibaba Cloud Pangu, providing high performance, high reliability, high availability, low cost, elastic storage, and robust security. All virtual warehouses read from and write to this shared storage layer.
-
Virtual warehouse (compute): Each virtual warehouse is an independent, elastically scalable compute unit that executes query requests. Because virtual warehouses do not share compute resources, one virtual warehouse's workload does not affect the performance of others. The Leader virtual warehouse handles write tasks; both Leader and Follower virtual warehouses handle query tasks.
-
Cloud service components: Gateway, Meta Service, and Holo Master provide metadata management, security authentication, provisioning, and node management. The Gateway routes each incoming connection to the frontend (FE) of the appropriate virtual warehouse — for example, a connection targeting the
read_warehousevirtual warehouse is forwarded to an FE ofread_warehouse.
Gateway connection capacity:
| Version | Peak new connections/second | Maximum connections |
|---|---|---|
| V2.2.22 and later | 150 | 8,000 |
| V2.0–V2.2.21 | 100 | 8,000 |