Differences between VCU mode and CU mode

Updated at:

Tablestore offers two billing methods: Virtual Compute Unit (VCU) mode, formerly known as reserved mode, and Compute Unit (CU) mode, formerly known as pay-as-you-go mode. This topic describes the differences between these modes and recommends scenarios for each.

Background information

Tablestore provides CU mode, which features elastic scaling, pay-as-you-go billing, and the separation of storage and compute.

To help users better estimate and control costs, Tablestore introduced VCU mode as an alternative to CU mode.

VCU mode provides predictable billing and supports elasticity, which lets you dynamically adjust VCU configurations based on your needs.

Differences in billing methods

The main differences between VCU mode and CU mode are described in the following list. For a detailed comparison, see the table below.

  • Compute

    VCU mode is a subscription-based method for purchasing compute capacity in the form of VCUs (4-core, 16 GB units). It also supports elasticity, where you are billed for the actual compute resources used, which are converted to VCUs. In contrast, CU mode bills you based on your actual compute consumption, which is converted to CUs.

  • Storage

    In VCU mode, charges are based on different storage classes. In CU mode, the storage class is determined by the instance type.

  • Index

    In VCU mode, index storage is billed separately, and index compute uses the general compute resources. In CU mode, index billing includes charges for high-performance storage and reserved CUs.

Difference

VCU mode

CU mode

Instance type

Medium

  • High-performance

  • Storage-optimized

Compute billing

  • Standardized VCU: 4-core 16 GB.

    • Reserved VCUs are billed by subscription.

    • With elasticity enabled, billing is based on actual compute resource consumption.

  • Purchase resources in advance based on usage estimates.

  • Covers compute consumption for reads, writes, index computation, and channels.

  • Billed hourly based on the actual CUs consumed.

  • Consumption is calculated at different rates for pay-as-you-go read CUs, pay-as-you-go write CUs, reserved read CUs, and reserved write CUs.

  • Consumption is calculated at different rates for high-performance and storage-optimized instances.

Storage billing

  • Billed hourly based on actual storage usage.

  • Differentiates between high-performance and storage-optimized storage classes.

  • Billed hourly based on actual storage usage.

  • Only one storage class is available, based on the instance type.

Billing for Search Indexes

  • The compute part consumes VCU resources for reads and writes.

  • The storage part is billed separately per hour for search index storage.

  • The compute part consumes reserved CUs based on storage space and the number of rows.

  • The storage part is billed hourly based on the total data volume of the search index.

Elasticity

Both compute and storage support elastic scaling.

Both compute and storage support elastic scaling.

Recommended scenarios

Billing method

Payment method

Description

Scenarios

VCU mode (previously reserved mode)

Primarily subscription, with support for elasticity

  • Compute: Pre-purchase reserved VCUs based on resource estimates, or pay for actual compute consumption after you enable elasticity. You can combine reserved VCUs and elasticity to save costs.

  • Storage: Scales dynamically. Billed hourly based on actual usage. No capacity planning is required.

  • Workloads with stable and predictable peak traffic.

  • Need for flexible elasticity with controllable overall costs.

  • Budget-based projects that require pre-purchased resources.

CU mode

Pay-as-you-go, billed hourly based on actual usage

This is a serverless model. No hardware resource planning is needed. Billing is based on real-time read/write throughput and the storage space used.

  • Workloads with large and unpredictable fluctuations in traffic.

  • Need for flexible elasticity with low O&M costs.

  • Scheduled tasks that require high throughput for short periods each day.