HUAWEI CLOUD RDS → STACKIT · GUIDE
Huawei Cloud RDS to STACKIT managed databases
A Huawei Cloud RDS instance does not move as one kind of thing: its db.type decides the target. PostgreSQL goes to PostgreSQL Flex, MariaDB to MariaDB, SQL Server to SQLServer Flex, and MySQL also to MariaDB, because STACKIT offers MariaDB and not MySQL. In the example run, four RDS instances become four REPLATFORM units of MEDIUM confidence, all in wave 3 behind the network units. The run names the target and a dump or restore route for each; the data mechanism, the downtime and the rollback stay with your database team.
The database migration in eight steps
1. Inventory each instance
Terraform shows engine, version, flavor, high availability mode, volume and backup window. It does not show the features your applications use, the size of the data or who connects. Collect those next to the files before you assess.
2. Assess and read the data file first
Run stacktoit assess on the root module. Open assessment.json for class, target and reason, then migration/data-movement.md: every RDS instance appears there as a stateful unit with the state DECISION_REQUIRED and the mechanism UNKNOWN.
3. Settle the target per engine
Use the table below. The one that needs care is MySQL: the run states that STACKIT offers MariaDB, not MySQL, so MySQL-specific features have to be tested before cut-over.
4. Build the network the databases depend on
The VPC and the security group are wave 1, the subnet wave 2, and all four databases wave 3. Create the STACKIT networks and the rules for the database ports first. STACKIT security group rules only allow traffic.
5. Create and size the target instances
A Huawei flavor becomes a Flex flavor or a STACKIT plan, so you pick the target size yourself. For PostgreSQL Flex the architecture page says storage size and performance class are chosen separately and the performance class cannot be changed after creation, so choose it on purpose, and enable instance protection, which API v3 added (generally available since 1 August 2026), on production instances, as the PostgreSQL Flex overview recommends.
6. Rehearse the data move
Copy a real dataset, time it and compare row counts or checksums. For PostgreSQL the run names pg_dump and pg_restore or logical replication, for MariaDB and MySQL a logical dump, for SQL Server a backup and restore. These are the routes the run names; you decide and measure.
7. Cut over with a way back
Stop writes, run the final copy, switch connection strings, and keep the Huawei instance until your checks pass. After the switch, new writes exist only on STACKIT, so decide beforehand whether a way back means a reverse copy or an accepted loss. The plan leaves this to the person who carries out the step.
8. Retire the source
Delete the RDS instance and its backups only after the retention you need has passed. Land the MariaDB 10.5 instance of the example directly on 10.11 or newer: as of November 2026, STACKIT has deprecated MariaDB 10.6, plans to decommission it on 1 July 2027 and asks customers to delete old instances after upgrading, because they keep costing money.
PostgreSQL and MySQL on RDS, assessed
A small Huawei Cloud estate written for this page and assessed by StackToIT on 4 November 2026: one network, one security group and four RDS instances. Left: two RDS blocks of the input. Right: the result the run recorded for them, an excerpt of assessment.json with the values as the run wrote them. The flavor codes in the input are illustrative.
resource "huaweicloud_rds_instance" "orders" {
name = "ledger-orders"
flavor = "rds.pg.n1.large.2.ha"
ha_replication_mode = "async"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.app.id
security_group_id = huaweicloud_networking_secgroup.app.id
availability_zone = ["eu-west-101a", "eu-west-101b"]
db {
type = "PostgreSQL"
version = "16"
password = var.db_password
}
volume {
type = "ULTRAHIGH"
size = 200
}
backup_strategy {
start_time = "02:00-03:00"
keep_days = 14
}
}
resource "huaweicloud_rds_instance" "crm" {
name = "ledger-crm"
flavor = "rds.mysql.n1.large.2"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.app.id
security_group_id = huaweicloud_networking_secgroup.app.id
availability_zone = ["eu-west-101a"]
db {
type = "MySQL"
version = "8.0"
password = var.db_password
}
volume {
type = "ULTRAHIGH"
size = 100
}
}[
{
"id": "huaweicloud_rds_instance.orders",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT PostgreSQL Flex"
},
"reason": "Managed PostgreSQL to managed PostgreSQL: data moves with pg_dump/pg_restore or logical replication, and the flavor becomes a Flex flavor."
}
},
{
"id": "huaweicloud_rds_instance.crm",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT MariaDB"
},
"reason": "STACKIT offers MariaDB, not MySQL; test MySQL-specific features before cut-over, and move the data with a logical dump."
}
}
]High availability is yours to rebuild
The orders instance runs as a primary and a standby in two zones. The run lists the zones and the backup settings among the settings left to you, 14 for this instance. On STACKIT a replica set has three nodes, so the topology is a design decision, not a copy.
MySQL is the exception
The crm instance is MySQL 8.0 and lands on MariaDB. The reason says it plainly: test MySQL-specific features before cut-over and move the data with a logical dump.
Passwords stay out
db.password is read from a sensitive variable that has no value in the run. The run reports it as a missing input, asks for nothing and never needs the secret to classify the instance.
MariaDB and SQL Server on RDS, assessed
The other two instances of the same run, in the same layout.
resource "huaweicloud_rds_instance" "legacy" {
name = "ledger-legacy"
flavor = "rds.mariadb.n1.large.2"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.app.id
security_group_id = huaweicloud_networking_secgroup.app.id
availability_zone = ["eu-west-101a"]
db {
type = "MariaDB"
version = "10.5"
password = var.db_password
}
volume {
type = "ULTRAHIGH"
size = 50
}
}
resource "huaweicloud_rds_instance" "reporting" {
name = "ledger-reporting"
flavor = "rds.mssql.2019.se.x1.large.2"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.app.id
security_group_id = huaweicloud_networking_secgroup.app.id
availability_zone = ["eu-west-101a"]
db {
type = "SQLServer"
version = "2019_SE"
password = var.db_password
}
volume {
type = "ULTRAHIGH"
size = 100
}
}[
{
"id": "huaweicloud_rds_instance.legacy",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT MariaDB"
},
"reason": "Managed MariaDB to STACKIT MariaDB: data moves with a logical dump, and the flavor becomes a STACKIT plan."
}
},
{
"id": "huaweicloud_rds_instance.reporting",
"result": {
"class": "REPLATFORM",
"confidence": "MEDIUM",
"target": {
"service": "STACKIT SQLServer Flex"
},
"reason": "Managed SQL Server to SQLServer Flex: check the edition and features in use, and move the data with a backup and restore."
}
}
]MariaDB 10.5 lands on a newer version
As of November 2026, the STACKIT MariaDB page deprecates 10.6, schedules its decommissioning for 1 July 2027 and recommends 10.11 or newer, so a 10.5 source moves together with a version upgrade. Test the application against the target version.
SQL Server needs a feature check
The run asks you to check the edition and the features in use. The STACKIT page lists replication, linked servers, Database Mail, Transparent Data Encryption and FILESTREAM as unsupported, and restore only into a new database.
How each RDS engine maps
| RDS engine (db.type) | STACKIT target | What to settle |
|---|---|---|
| PostgreSQL | PostgreSQL Flex · REPLATFORM | Flex flavor, single instance or three-node replica set, storage class, extensions. Data by pg_dump and pg_restore or logical replication. |
| MySQL | MariaDB · REPLATFORM | The run notes STACKIT offers MariaDB, not MySQL. Test MySQL-specific features, then move with a logical dump. |
| MariaDB | MariaDB · REPLATFORM | Target version 10.11 or newer, STACKIT plan instead of flavor, logical dump. |
| SQL Server | SQLServer Flex · REPLATFORM | Edition and features in use, unsupported features, backup and restore into a new database. |
Targets and classes as the run decided them for the four instances; the right column combines the run reasons with the STACKIT documentation read for this page. The Huawei Cloud provider documents four values for db.type: MySQL, PostgreSQL, SQLServer and MariaDB.
Four stateful units, no mechanism chosen
Left: the stateful table of migration/data-movement.md. Right: wave 3 of migration/technical-sequencing.md. Both are lines as the run wrote them.
## Stateful source units
| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| huaweicloud_rds_instance.crm | huaweicloud_rds_instance | STACKIT MariaDB | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| huaweicloud_rds_instance.legacy | huaweicloud_rds_instance | STACKIT MariaDB | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| huaweicloud_rds_instance.orders | huaweicloud_rds_instance | STACKIT PostgreSQL Flex | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| huaweicloud_rds_instance.reporting | huaweicloud_rds_instance | STACKIT SQLServer Flex | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |## Wave 3 — 4 unit(s)
| Unit | Class | Target |
|---|---|---|
| `huaweicloud_rds_instance.crm` | REPLATFORM / MEDIUM | STACKIT MariaDB |
| `huaweicloud_rds_instance.legacy` | REPLATFORM / MEDIUM | STACKIT MariaDB |
| `huaweicloud_rds_instance.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |
| `huaweicloud_rds_instance.reporting` | REPLATFORM / MEDIUM | STACKIT SQLServer Flex |Nothing is moved for you
StackToIT never moves data. The mechanism stays UNKNOWN until a person chooses it from data size, tolerated downtime and the consistency the application needs.
NOT_PROVIDED is an invitation
Data class, RPO and downtime tolerance are the customer’s to state in an applications file. Until then the run assumes nothing.
Decisions that stay with your database team
Topology
One instance or a three-node replica set per database, and in which zones. The source standby setup is an input, not a template.
Version
The target version per engine, checked against what the application supports.
Backups and recovery
The PostgreSQL instance of the example keeps 14 days of backups. The STACKIT PostgreSQL Flex page describes transaction logs on by default and point-in-time recovery; define the retention and the restore drill yourself.
Feature gaps
MySQL features without a MariaDB equal, SQL Server features the STACKIT page lists as unsupported, PostgreSQL extensions you rely on.
Cutover and rollback
The window, the connection-string switch and the way back, written per database before the first rehearsal.
Ownership
The run assigns the four steps to the Data Architect role as a starting point. Replace it with real people.
Questions database teams ask
Where does a Huawei Cloud RDS MySQL instance go on STACKIT?
The run maps it to STACKIT MariaDB as a REPLATFORM unit, with the reason that STACKIT offers MariaDB, not MySQL. Test MySQL-specific features before cut-over and move the data with a logical dump. The MariaDB page presents MySQL compatibility as a feature, which makes the test cheap but does not replace it.
Does StackToIT copy the data?
No. It lists each database as a stateful unit, shows the mechanism as UNKNOWN and the state as DECISION_REQUIRED, and names routes such as pg_dump and pg_restore. You choose, rehearse and measure.
Does the run need the database passwords?
No. The run completes without them: the unset sensitive variable db_password is reported as a missing input, the source is marked VARIABLE_UNRESOLVED and the answer template lists it as a request that blocks the draft. The template never takes the value itself; it comes from a variable file or TF_VAR_db_password, only if you want it in the run.
Is a STACKIT Terraform draft written for the databases?
Not in this build. The run writes terraform.tf, variables.tf and a README, and lists the four instances as left for the architect with their critical settings: 14 for the PostgreSQL instance and 11 for each of the others.
Sources
Your next move: STACKIT.
Tell us about your estate. We show you what StackToIT delivers for it: target architecture, Terraform artifacts and a structured migration plan.