All Products
Search
Document Center

Hologres:Convert general purpose instances to virtual warehouse instances

Last Updated:Mar 26, 2026

Virtual warehouse instances offer finer-grained load isolation, more flexible permission management, and easier connection management than general-purpose instances. Each virtual warehouse has its own configuration, so you can tune resources independently per workload. This topic describes how to convert a Hologres general-purpose instance to a virtual warehouse instance.

Prerequisites

Before you start, confirm that your instance meets all of the following conditions:

  • Version: The instance runs Hologres V2.0.40 or later. If the version is earlier than V2.0.40, upgrade the instance manually in the Hologres console, or contact technical support by joining the Hologres DingTalk group. For upgrade instructions, see the "Manual upgrade" section of Instance upgrades. For information about getting technical support, see Obtain online support for Hologres.

  • Specifications: The instance has more than 8 CPU cores. Instances with 8 CPU cores cannot be converted. To proceed, change the instance specifications first. For more information, see Instance configurations.

  • Instance role: The instance is not a read-only secondary instance. Read-only secondary instances cannot be converted directly. To convert a primary instance that has read-only secondary instances, see Convert a primary/secondary instance.

  • Direction: You are converting from general-purpose to virtual warehouse, not the reverse. Converting a virtual warehouse instance back to a general-purpose instance is not supported.

Conversion methods

Two methods are available. Choose based on whether your business can tolerate a brief write interruption.

Important

Run the conversion during off-peak hours. Service downtime during normal conversion is not covered by the SLA.

Normal conversion Hot conversion
Duration Typically 10–20 minutes Typically 10–30 minutes
Service state Fully unavailable Read-only (queries unaffected, writes unavailable)
Flink data ingestion jobs Stop before conversion; restart after to avoid data loss. See Stop a job.
DataWorks / Blink jobs No action needed. Failovers trigger automatically. Set failover retries to 10 or more. See O&M for real-time sync tasks for DataWorks tasks and Write data to Hologres from real-time computing (Blink) for Blink jobs.
Endpoint Unchanged, but the IP address may change Unchanged, but the IP address may change
How to request Submit a ticket or contact technical support. See How do I get more online support? Same as normal conversion

Convert a general-purpose instance

A general-purpose instance has a single endpoint. After conversion, the endpoint and all metadata — including user permissions — remain unchanged.

To start the conversion, submit a ticket or join the Hologres DingTalk group with the instance ID and your preferred operation time. Hologres O&M engineers will perform the conversion in the background.

After conversion, set up load isolation for your virtual warehouses. See (Recommended) Set up load isolation.

Convert a primary/secondary instance (primary as general-purpose)

Primary/secondary instances use a multi-endpoint load isolation architecture. Virtual warehouse instances use a single-endpoint architecture. Before converting, you must consolidate traffic to the primary instance and release the secondary instances.

The following example uses a primary instance with 64 compute units (CUs) and two read-only secondary instances each with 32 CUs:

  1. Scale up the primary instance to 128 CUs — the combined total of the primary and secondary instances. This ensures the primary instance can absorb all traffic while you migrate workloads, without service interruption.

  2. Migrate query traffic from the read-only secondary instances to the primary instance.

  3. Disassociate or release the read-only secondary instances. For more information, see Instances. The primary instance is now a standalone general-purpose instance.

  4. Submit a ticket or join the Hologres DingTalk group with the instance ID and preferred operation time. Hologres O&M engineers will complete the conversion.

After conversion, set up load isolation for your virtual warehouses. See (Recommended) Set up load isolation.

Parameter changes after conversion

Parameter Before After
Instance type General-purpose Virtual warehouse
Number of gateway nodes N/A Default: CUs ÷ 32 (valid range: 2–8). Adjustable after conversion — see Manage virtual warehouses.
Computing resources Supported Unchanged. All CUs are allocated to the default init_warehouse virtual warehouse.
Note

The endpoint remains unchanged after conversion, but the IP address may change.

What to do next

(Important) Configure alert rules

After conversion, your instance moves from the Hologres standard instance tab to the Hologres warehouse instance tab in the CloudMonitor console. This update takes approximately 10 minutes.

  • If no alert rules exist, configure them for key metrics on the Hologres warehouse instance tab. See the Configure alert rules section.

  • If alert rules already exist, reconfigure them on the Hologres warehouse instance tab. Consider adding gateway-related metrics that are now available for virtual warehouse instances.

(Recommended) Set up load isolation

After conversion, all computing resources are assigned to the default init_warehouse virtual warehouse. To isolate different workloads — for example, separating online analytical processing (OLAP) queries from online services — create dedicated virtual warehouses and route traffic accordingly.

The following example uses a 128-CU instance:

  1. After the O&M engineers complete the conversion, all 128 CUs are allocated to init_warehouse. Scale up the instance first so that init_warehouse has enough capacity to absorb traffic while you build out the new virtual warehouses — this prevents service interruption during the transition. For more information, see Scale up a virtual warehouse. For example, increase the reserved computing resources to 192 CUs. The 64 CUs of unallocated capacity will be assigned to new virtual warehouses in the next step.

  2. Create virtual warehouses for each workload. For more information, see Create a virtual warehouse. For example, create warehouse_olap with 32 CUs for OLAP and warehouse_serving with 32 CUs for online services.

  3. Grant the appropriate users access to each virtual warehouse. See Manage permissions on virtual warehouses. Then grant permissions on the table groups loaded to each warehouse. See Manage data permissions. Switch the corresponding business traffic to the new virtual warehouses.

  4. Scale down init_warehouse now that the other virtual warehouses are handling their respective workloads. For more information, see Scale down a virtual warehouse. For example, reduce init_warehouse to 64 CUs, then decrease the instance's reserved computing resources from 192 CUs to 128 CUs. All virtual warehouses remain available during the scale-down.

For more information on the overall setup process, see:

(Optional) Enable additional features

Enable the following features per virtual warehouse based on your requirements:

  • Scheduled scaling (beta): Automatically scale a virtual warehouse at scheduled times. See Scheduled scaling (beta).

  • Serverless Computing: Run on-demand compute without pre-provisioned resources. See Serverless Computing.

References

For information about the virtual warehouse instance architecture, see Architecture.