All Products
Search
Document Center

MaxCompute:Choose a billing method

Last Updated:Mar 26, 2026

MaxCompute offers three billing methods—subscription, pay-as-you-go, and hourly billing—each suited to different workload patterns. This page helps you match the right method to your workload and estimate costs before committing.

Billing methods

Each billing method is designed for a specific type of workload. Choosing the wrong one can lead to idle resources (if you over-provision) or budget unpredictability (if you under-provision).

Billing method How it works Best for
Subscription Computing resources are charged monthly or annually. Storage and download are billed on a pay-as-you-go basis. Frequent, predictable workloads where you can forecast compute needs in advance
Pay-as-you-go Storage, computing, and download are all billed based on actual usage. No upfront commitment or resource sizing required. Unpredictable or exploratory workloads where sizing resources upfront is difficult
Hourly billing Use subscription resources as a baseline; extra capacity is charged hourly based on the number of compute units (CUs) added and the duration of use. Workloads with a predictable baseline but occasional demand spikes

For a full description of each method, see Overview.

Estimate costs before switching

Before committing to a billing method, use the following tools to model your expected spend.

MaxCompute price calculator

Use the MaxCompute price calculator_V5.xlsx) for subscription billing. Enter your required computing resources and estimated data upload and download volumes to get a monthly cost estimate.

CostSQL

Use CostSQL for pay-as-you-go billing. CostSQL estimates the cost of a SQL job before it runs in production.

  • Run the COST SQL command to get an estimate before executing a SQL job. For details, see Cost estimation.

  • In IntelliJ IDEA, cost estimates are generated automatically when you submit a SQL script. For details, see Develop and submit a SQL script.

  • In DataWorks, cost estimation is also available.

CostSQL cannot estimate costs for all SQL jobs. Jobs that involve external tables, for example, cannot be estimated. Treat estimates as planning inputs—actual costs reflect final bills.

Cost estimates for 1 TB of data

The following table shows estimated monthly costs for processing 1 TB of data under different billing methods and workload types.

Billing method Workload type CUs used Response time Estimated monthly cost
Subscription Compute-intensive 160 CUs Within a few minutes 3768 USD
Subscription Storage-intensive ~50 CUs Within a few hours USD 1,177.5
Pay-as-you-go SQL complexity 1, once per day 1,413 USD

How these numbers are calculated:

  • Subscription, compute-intensive: 160 CUs x monthly CU price = USD 3,768/month. Use this configuration when jobs must finish within a few minutes.

  • Subscription, storage-intensive: ~50 CUs x monthly CU price = USD 1,177.5/month. Use this when jobs can run over a few hours and strict latency is not required.

  • Pay-as-you-go: At SQL complexity 1, processing 1 TB costs USD 47.1/day. At once-per-day frequency, that totals USD 1,413/month. If the data is processed multiple times per day, multiply the daily cost accordingly.

To model your own scenario, substitute your actual CU count and processing frequency into the same formula.

Assess the CUs you need

If you don't know how many CUs to purchase for a subscription plan, follow these steps:

  1. Start with pay-as-you-go billing. If you are migrating data to the cloud for the first time, we recommend starting here.

  2. Run a Proof of Concept (POC) test that represents your real workload.

  3. After the test, query TASKS_HISTORY in the Information Schema service to retrieve the total CU-hours consumed.

  4. Calculate the number of CUs you need to purchase based on the total CU-hours.

  5. Purchase subscription CUs based on that number.

Choose a billing strategy

Single billing method

  • Subscription works well when jobs are frequent and predictable. It provides cost certainty and faster job throughput.

  • Pay-as-you-go works well when jobs are infrequent or hard to size. There is no upfront commitment, and you pay only for what you use.

Mixed billing

Combining billing methods lets you optimize cost across different job types.

Option 1: Subscription for periodic production workloads + pay-as-you-go for aperiodic jobs

Use subscription for extract, transform, load (ETL) jobs that run on a fixed schedule. Use pay-as-you-go for ad hoc queries and one-off data processing jobs. In pay-as-you-go mode, jobs can read from tables owned by other accounts, which avoids duplicating storage. Cross-account access requires authorization; see Create a project-level role.

Option 2: Subscription for aperiodic jobs + pay-as-you-go for daily production workloads

If development and testing jobs generate unpredictable costs, add them to fixed resource groups and configure custom development and business intelligence (BI) groups in MaxCompute Management. If production ETL jobs run only once per day, assign them to a pay-as-you-go resource group to avoid paying for idle subscription capacity.

Hadoop migration

If you are migrating from Hadoop, the compute-intensive subscription scenario provides a useful reference point. A typical Hadoop cluster with one controller node and five compute nodes—each with 32 cores (160 CPUs total)—costs approximately USD 3,768/month with no discounts applied. MaxCompute does not require controller nodes, and its performance is 80% higher than Hive, which reduces both operations and maintenance (O&M) overhead and cost.

Switch billing methods

If your data volume changes and your current subscription resources are under- or over-provisioned, upgrade or downgrade the configuration. For details, see Upgrade or downgrade configurations.

To switch between billing methods entirely, see Switch billing methods.

Important

Before switching to subscription, evaluate your job performance and cycle times to determine the right CU count. If you purchase too few CUs, job execution time increases and throughput drops, which may require switching again.

What's next