MaxCompute and AnalyticDB: designing the STACKIT target

The design question

A like-for-like service swap is not on offer, so the migration starts with a decision about the target architecture.

• What MaxCompute is

  Alibaba Cloud documents it as a fully managed online data warehouse service on a serverless architecture that decouples storage from compute, bills pay-as-you-go and offers Standard, Infrequent Access and Archive storage classes. Its compute layer runs several engines for offline, near real-time and Data+AI tasks, and it adds the MaxFrame distributed computing framework.

• What AnalyticDB for MySQL is

  A managed analytical service that, in Alibaba Cloud's words, is highly compatible with MySQL and built on a data lakehouse architecture, so existing clients, drivers and BI tools that speak MySQL generally work. It comes as an Enterprise Edition for production and a Basic Edition for learning and testing, and it can keep historical data in OSS.

• What the target must give back

  Somewhere to land the tables, a SQL engine for the queries, a way to load and refresh data, and an access path for the tools that connect today. None of the four is one STACKIT service.

• Who owns the answer

  Your data architects. The run proposes the family of target and the reason; sizing, engine choice and the query port are theirs.

What the run records for the two services

A small Alibaba Cloud estate written for this page: a MaxCompute project, an AnalyticDB cluster and the network under it, assessed by StackToIT on 4 November 2026. Left: the input. Right: the result for each service, an excerpt of assessment.json with the values exactly as the run wrote them (the target service name is left out of the excerpt). assessment.json is written as a single line, so the pane shows selected fields of each unit, indented and nested as in the file, with the values unchanged. The demo pins aliyun/alicloud 2.1.0; the attribute names of the project and the cluster match that version's registry documentation, but OpenTofu did not validate the input.

resource "alicloud_maxcompute_project" "warehouse" {
  project_name = "sales_dwh"
  comment      = "nightly sales warehouse"
}

resource "alicloud_adb_db_cluster" "reporting" {
  db_cluster_category = "Cluster"
  mode                = "flexible"
  compute_resource    = "8Core32GB"
  db_cluster_version  = "3.0"
  payment_type        = "PayAsYouGo"
  vswitch_id          = alicloud_vswitch.adb.id
  vpc_id              = alicloud_vpc.data.id
  zone_id             = "eu-central-1a"
  description         = "reporting"
}

{
  "id": "alicloud_maxcompute_project.warehouse",
  "result": {
    "class": "REDESIGN",
    "confidence": "MEDIUM",
    "target": {
      "resources": [
        "stackit_dremio_instance"
      ]
    },
    "reason": "MaxCompute has no managed counterpart. The data and SQL dialect move to a redesigned lakehouse or warehouse."
  }
}

{
  "id": "alicloud_adb_db_cluster.reporting",
  "result": {
    "class": "REDESIGN",
    "confidence": "LOW",
    "target": {
      "resources": [
        "stackit_dremio_instance"
      ]
    },
    "reason": "AnalyticDB has no managed counterpart. The data and queries move to a redesigned lakehouse or warehouse."
  }
}

• Both REDESIGN

  The reasons read alike: no managed counterpart, so the data and the SQL dialect or queries move to a redesigned lakehouse or warehouse.

• Confidence differs

  MaxCompute is rated MEDIUM, AnalyticDB LOW. The AnalyticDB cluster also names the VPC and vSwitch under it, and a redesign has to re-make those references.

• Settings named

  Two settings are listed for the project (comment, project_name) and nine for the cluster (among them compute_resource, db_cluster_category, db_cluster_version, description and mode). They are inputs to sizing, not values that carry over.

• One candidate resource

  The run lists stackit_dremio_instance as the candidate resource. The STACKIT provider treats it as an opt-in feature that may still change, and the run records that as a limit: the unit needs a person's review and is not drafted for automation while it is.

Three options for the target

The first two follow the run. The third is a common architect’s variant of them; the run does not classify it.

Neither option is a service that reads Alibaba Cloud queries. Every query is reviewed, ported and compared with its old result.

How to decide

Work through these questions in order. Each one removes an option or gives you a number for the sizing.

1. 01

   1. Inventory the data, not the service

   List tables, size, growth, retention and who reads them. The Terraform shows a project and a cluster, not what is inside, and the run reads only the Terraform. Its data-movement file for this estate reads NOT APPLICABLE (see below), so the inventory of what has to move is yours to build.

2. 02

   2. Separate batch from interactive

   Alibaba Cloud documents engines for offline, near real-time and Data+AI tasks in MaxCompute, and real-time analytics, with data queryable milliseconds after it is written, as the focus of AnalyticDB. Different latency needs often justify different engines on the target.

3. 03

   3. List the clients

   AnalyticDB is reached with MySQL-protocol clients. Count the BI tools, drivers and scheduled jobs that connect, and check each against the engine you pick. This is the usual source of surprise.

4. 04

   4. Port the SQL on a sample

   Take the ten most expensive and the ten most used queries. Run them on the candidate engine against a copy of their data. The result tells you more than any feature comparison.

5. 05

   5. Decide who operates it

   A managed layer shifts upgrades and scaling to the provider; a self-managed engine puts them on your platform team. Count that effort in people, not in service names.

6. 06

   6. Plan the load

   Choose a loading path from the old store to Object Storage and a verification of row counts and aggregates before any consumer switches. The run chooses none.

The order the run gives, and what its data file says

migration/technical-sequencing.md puts the four units into three waves: the MaxCompute project and the VPC in wave 1, the vSwitch in wave 2 and the AnalyticDB cluster in wave 3, after the network it names. Below: the data-movement file of the same run, an excerpt taken as written.

StackToIT never moves data. The source was read in full and holds no database, cache, search domain, warehouse, volume, file share or object store. Data that lives on the disks of a server or virtual machine is not looked at, so this does not say that no data has to move.

State: NOT APPLICABLE.

• Network first

  The VPC and vSwitch are RECONFIGURE / MEDIUM units and come before the cluster; the cluster, REDESIGN / LOW, is in wave 3 because it names both.

• MaxCompute in wave 1

  The project depends on nothing in the estate, so its design can start at once. Its data lives inside the service, so the real work is the inventory.

• Read the data file with care

  For this estate the file reads NOT APPLICABLE and says the source holds no warehouse, although both REDESIGN units are warehouses. Treat the tables of both services as data that has to move, and plan the load yourself.

Risks to put on your register

• Dialect and function gaps

  Plan a port, not a copy. Unknown functions, partitioning and UDFs surface only when queries run.

• Result differences

  Compare aggregates, not only row counts. Rounding, null handling and time zones differ between engines.

• Data egress

  Reading the data out of Alibaba Cloud may be charged. Check your own terms before choosing a load path.

• Provider changes

  The Dremio resource of the STACKIT provider may still change. Pin the provider version and read its release notes before each run.

Questions about MaxCompute and AnalyticDB

Sources

• Alibaba Cloud: what is MaxCompute
• Alibaba Cloud: what is AnalyticDB for MySQL
• STACKIT Docs: Dremio overview
• STACKIT Docs: introduction to Object Storage
• STACKIT Docs: limits of Object Storage
• Terraform Registry: alicloud_adb_db_cluster (provider 2.1.0)