All Products
Search

This Product

    Hologres:Prepare an instance for production workloads

    Document Center

    Hologres:Prepare an instance for production workloads

    Last Updated:Jun 17, 2026

    To run performance tests or deploy a Hologres trial instance in production, you must upgrade it to handle higher workloads. Without an upgrade, resource shortages can cause increased latency, slower processing, or service interruptions. This topic uses an 8-Core trial instance as an example.

    Step 1: Upgrade the instance

    Hologres 8-Core instances are intended only for evaluation and functional testing. Do not use them for performance testing or production workloads.

    To run performance tests or deploy production jobs, you must first upgrade the instance, for example, to a 64-Core instance. For more information, see Upgrade or downgrade instances.

    Step 2: Modify the shard count

    Hologres stores data across multiple partitions called shards. Setting an appropriate shard count enables better use of distributed computing resources and parallel processing, which improves query performance.

    An 8-Core instance defaults to 2 shards. After an upgrade, the shard count stays at 2 even though the number of compute nodes (Workers) increases, which prevents the system from fully using its distributed query capabilities. You must adjust the shard count after the upgrade. For more information, see Manage table groups and shard counts.

    Note

    You can also perform the following steps in the HoloWeb console. For more information, see Table group management.

    1. Create a new Table Group with an appropriate shard count.

      For a 64-Core Hologres instance, a shard count of 40 is recommended. Run the following command to create a new Table Group and set its shard count:

      CALL HG_CREATE_TABLE_GROUP ('<new_tg_name>', <shard_count>);

      In this command, new_tg_name specifies the name of the new Table Group and shard_count specifies the number of shards.

    2. Set the new Table Group as the default group.

      Run the following command to set the new Table Group as the default. New tables that you create will automatically belong to this group.

      CALL HG_UPDATE_DATABASE_PROPERTY ('default_table_group', '<new_tg_name>');

    3. Migrate existing tables to the new Table Group.

      Existing tables still belong to the original Table Group. Run the following command to move an existing table to the new Table Group.

      -- Syntax for V1.1 and later
CALL HG_MOVE_TABLE_TO_TABLE_GROUP('<table_name>','<new_tg_name>');

-- Syntax for V0.10
CALL HG_UPDATE_TABLE_SHARD_COUNT('<table_name>','<new_tg_name>');

    (Optional) Resource isolation and high availability

    For read/write splitting or read-read separation, use the Hologres shared-storage multi-instance high availability (HA) solution. For more information, see Deploy primary and secondary instances for read/write splitting (shared storage).

    For example, with a 64-Core instance, you can configure a 32-Core primary instance for writes and a 32-Core read-only secondary instance for queries. To serve multiple query-intensive applications, add more read-only secondary instances for read-read separation.

    Next steps

    After your production workloads are running stably:

    • To reduce compute costs, switch the billing method from pay-as-you-go to subscription. For pricing details, see Billing. To change the billing method, see Switch between billing methods.

    • To reduce storage costs, you can purchase Standard storage resources on a subscription basis. To do this, you must first switch the instance to the subscription billing method and then upgrade it. .

    References