All Products
Search
Document Center

Hologres:Grant data access to virtual warehouses

Last Updated:Mar 26, 2026

Control which virtual warehouses can read from or write to each table group in a Hologres instance. Loading a table group into a virtual warehouse makes that warehouse a follower, enabling read access and optionally routing writes to the leader through DML auto-routing.

How it works

Each table group has exactly one leader virtual warehouse — the virtual warehouse in which the table group was created. Only the leader can perform DML operations (INSERT, UPDATE, DELETE) on tables in that table group.

Any other virtual warehouse can become a follower virtual warehouse by loading the table group into it. A follower can read tables in the table group but cannot write to them directly. To write from a follower, enable DML auto-routing, which transparently forwards write operations to the leader.

Memory state is synchronized from the leader to all followers in real time at the millisecond level. This synchronization adds a small amount of CPU and memory overhead to follower virtual warehouses. Keep the size difference between virtual warehouses within a 4x ratio to avoid performance degradation.

Version differences:

  • Hologres V2.0: A virtual warehouse must have a table group loaded to access it. Without loading, neither reads nor writes are possible.

  • Hologres V4.0: After you enable the GUC parameter hg_warehouse_enable_use_local_resource, virtual warehouses without the table group loaded can run read and write tasks that are not optimized by Fixed Plan. Real-time writes (Fixed Plan-optimized) still require the leader virtual warehouse. All write tasks, such as real-time and batch writes, can still be routed to the leader virtual warehouse for execution using the DML auto-routing feature.

The following table summarizes read/write capabilities by virtual warehouse type in Hologres V4.0:

Task type Leader virtual warehouse Follower virtual warehouse (table group loaded) Other virtual warehouses (table group not loaded)
Real-time write (Fixed Plan-optimized) Supported Not supported Not supported
Batch write (not Fixed Plan-optimized) Supported Supported (V4.0, GUC must be enabled) Supported (V4.0, GUC must be enabled)
Key/Value point query, Prefixscan (Fixed Plan-optimized) Supported Supported Not supported
Other read tasks (not Fixed Plan-optimized) Supported Supported Supported (V4.0, GUC must be enabled)
Only the default virtual warehouse of an instance can write data to foreign tables.

Prerequisites

Before you begin, ensure that you have:

  • Superuser permissions for the Hologres instance (required for all management operations in this topic)

  • An existing table group (see Manage table groups)

View table group access permissions for a virtual warehouse

Run the following SQL statement to view the table group permissions for all virtual warehouses in the current instance:

SELECT * FROM hologres.hg_warehouse_table_groups;

To check the permissions of a specific virtual warehouse, filter by warehouse name:

SELECT * FROM hologres.hg_warehouse_table_groups
WHERE warehouse_name = '<warehouse_name>';

The hg_warehouse_table_groups table contains the following columns:

Column Data type Description Example
warehouse_name TEXT The name of the virtual warehouse. init_warehouse
warehouse_id INTEGER The unique ID of the virtual warehouse. 1
database_name TEXT The name of the database. wh_demo
tablegroup_name TEXT The name of the table group. wh_demo_tg_default
leader BOOLEAN Whether this virtual warehouse is the leader for the table group. t
replica_count INTEGER The number of replicas. 1

Load a table group into a virtual warehouse

Loading a table group into a virtual warehouse makes that virtual warehouse a follower for the table group, enabling it to read tables in the group.

If a follower virtual warehouse executes a write operation with DML auto-routing disabled, the operation fails with an error. Enable DML auto-routing to forward writes to the leader automatically.

Syntax:

CALL hg_table_group_load_to_warehouse ('<database_name>.<table_group_name>', '<warehouse_name>', <replica_count>);

Parameters:

Parameter Type Description
database_name TEXT The name of the database.
table_group_name TEXT The name of the table group.
warehouse_name TEXT The name of the virtual warehouse to load the table group into.
replica_count INTEGER The number of replicas. Default: 1. Optional.

Examples:

-- Load table_group_1 in the db1 database into the warehouse_1 virtual warehouse with one replica.
CALL hg_table_group_load_to_warehouse ('db1.table_group_1', 'warehouse_1');

-- Load table_group_1 in the db1 database into the warehouse_1 virtual warehouse with two replicas.
CALL hg_table_group_load_to_warehouse ('db1.table_group_1', 'warehouse_1', 2);

Set the leader virtual warehouse for a table group

Each table group has exactly one leader virtual warehouse. To change the leader, run the following command. The new leader virtual warehouse restarts during the operation — plan for potential service impact before proceeding.

Syntax:

CALL hg_table_group_set_leader_warehouse ('<database_name>.<table_group_name>', '<warehouse_name>');

Parameters:

Parameter Type Description
database_name TEXT The name of the database.
table_group_name TEXT The name of the table group.
warehouse_name TEXT The name of the virtual warehouse to set as the leader.

Unload a table group from a virtual warehouse

Unloading removes follower access from the virtual warehouse. Before unloading, verify that the target virtual warehouse is not the current leader — you cannot unload a table group from its leader. Change the leader first if needed.

Syntax:

CALL hg_table_group_unload_from_warehouse ('<database_name>.<table_group_name>', '<warehouse_name>');

Parameters:

Parameter Type Description
database_name TEXT The name of the database.
table_group_name TEXT The name of the table group.
warehouse_name TEXT The name of the virtual warehouse to unload the table group from.

Change the number of replicas for a table group in a virtual warehouse

Syntax:

CALL hg_table_group_set_warehouse_replica_count ('<database_name>.<table_group_name>', <replica_count>, '<warehouse_name>');

Parameters:

Parameter Type Description
database_name TEXT The name of the database.
table_group_name TEXT The name of the table group.
replica_count INTEGER The new number of replicas.
warehouse_name TEXT The name of the virtual warehouse.

DML auto-routing for virtual warehouses (Beta)

DML auto-routing automatically forwards write operations from a follower virtual warehouse to the leader virtual warehouse of the table group. This lets applications connect to any follower and issue writes without manually routing to the leader.

Available starting with Hologres V2.2.

How it works: When enabled, write tasks run on the leader's resources. However, queries per second (QPS) metrics for those write operations are recorded on the follower, not the leader.

Important

DML auto-routing is incompatible with the multi-DML mixed transaction feature. If you enable multi-DML mixed transactions, disable DML auto-routing first. For details, see SQL transaction capabilities.

Enable or disable DML auto-routing

The GUC parameter hg_experimental_enable_warehouse_dml_auto_routing controls DML auto-routing. It is enabled by default.

Session level:

-- Enable DML auto-routing.
SET hg_experimental_enable_warehouse_dml_auto_routing = ON;

-- Disable DML auto-routing.
SET hg_experimental_enable_warehouse_dml_auto_routing = OFF;

Database level:

-- Enable DML auto-routing.
ALTER DATABASE <database_name> SET hg_experimental_enable_warehouse_dml_auto_routing = ON;

-- Disable DML auto-routing.
ALTER DATABASE <database_name> SET hg_experimental_enable_warehouse_dml_auto_routing = OFF;
Parameter Type Description
database_name TEXT The name of the database.

Example: verify DML auto-routing behavior

This example sets up a follower virtual warehouse and demonstrates how DML auto-routing affects write execution.

  1. Open the HoloWeb developer page.

  2. In the menu bar, click Security Center.

  3. In the left navigation pane, click Virtual Warehouse Management.

  4. On the Virtual Warehouse Resource Management tab, click Create Virtual Warehouse and create a virtual warehouse named read_wh1.

    Note Each instance supports up to 10 virtual warehouses. Each virtual warehouse requires between 32 CUs and 512 CUs of compute resources. If fewer than 32 CUs of unallocated compute resources are available, scale up your resources before creating a new virtual warehouse.

    image

  5. On the Management on Permissions of Virtual Warehouses on Table Groups tab, click Grant Permissions to Virtual Warehouse and set read_wh1 as a follower virtual warehouse for the target table group.

    image

  6. In the SQL Editor, switch the current virtual warehouse to read_wh1, then run a DML statement with auto-routing enabled and disabled to compare behavior:

    • Auto-routing enabled (default): The DML statement is automatically routed to the leader virtual warehouse (init_warehouse) for execution. image

    • Auto-routing disabled: The DML statement runs on read_wh1. Because read_wh1 is a follower and not the leader, the operation fails with an error. image

What's next