HUAWEI CLOUD GAUSSDB → STACKIT · ARCHITECTURE
GaussDB to STACKIT: MySQL and openGauss options
GaussDB is not a single product. GaussDB(for MySQL) separates compute from shared storage and speaks MySQL; the openGauss-based edition speaks a PostgreSQL-related dialect and can be distributed. STACKIT has no managed twin of either, so the assessment classifies both as REDESIGN with LOW confidence and proposes MariaDB and PostgreSQL Flex as the places to test. This page sets out the options, what the run does and does not decide, and how an architect chooses.
Two GaussDB instances, assessed
A small Huawei Cloud estate written for this page and assessed by StackToIT on 4 November 2026. Left: a GaussDB(for MySQL) instance with two read replicas and a distributed openGauss instance. Right: the results recorded for them, excerpts of assessment.json with the values as the run wrote them.
resource "huaweicloud_gaussdb_mysql_instance" "orders" {
name = "orders-mysql"
password = var.db_password
flavor = "gaussdb.mysql.4xlarge.x86.4"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.data.id
security_group_id = huaweicloud_networking_secgroup.db.id
read_replicas = 2
backup_strategy {
start_time = "03:00-04:00"
keep_days = 7
}
}
resource "huaweicloud_gaussdb_opengauss_instance" "ledger" {
name = "ledger-og"
password = var.db_password
flavor = "gaussdb.opengauss.ee.dn.m6.2xlarge.8.in"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.data.id
security_group_id = huaweicloud_networking_secgroup.db.id
availability_zone = "eu-west-101a,eu-west-101b,eu-west-101c"
sharding_num = 1
coordinator_num = 2
ha {
mode = "enterprise"
replication_mode = "sync"
consistency = "strong"
}
volume {
type = "ULTRAHIGH"
size = 40
}
}{
"id": "huaweicloud_gaussdb_mysql_instance.orders",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"target": {
"service": "STACKIT MariaDB",
"resources": [
"stackit_mariadb_instance",
"stackit_mariadb_credential"
]
},
"reason": "GaussDB(for MySQL) separates compute from shared storage, which has no STACKIT counterpart. STACKIT offers MariaDB, not MySQL; test the workload there before cut-over."
}
}
{
"id": "huaweicloud_gaussdb_opengauss_instance.ledger",
"result": {
"class": "REDESIGN",
"confidence": "LOW",
"target": {
"service": "STACKIT PostgreSQL Flex",
"resources": [
"stackit_postgresflex_instance",
"stackit_postgresflex_database",
"stackit_postgresflex_user"
]
},
"reason": "GaussDB is not PostgreSQL, although its SQL is related. Schema, procedures and clients need a conversion and a test on PostgreSQL Flex."
}
}REDESIGN, LOW
Neither engine is a drop-in. The run proposes MariaDB for the MySQL one and PostgreSQL Flex for the openGauss one, both as candidates to test, and classifies each as REDESIGN with LOW confidence.
Nine and fourteen settings named
The MySQL instance leaves nine settings to you, among them flavor, read_replicas and the backup window. The openGauss instance leaves fourteen, among them the HA mode, the replication mode, sharding_num and coordinator_num.
Nothing drafted
For a Huawei Cloud source this build writes no STACKIT resource blocks. The databases, like the network around them, are manual steps with an owner.
The options per workload
Four ways to land a GaussDB workload on STACKIT. The first two are what the run proposes. The last two are general practice that the run does not draft.
| Option | What changes for you | Choose it when |
|---|---|---|
| MariaDB on STACKIT, for GaussDB(for MySQL) | The shared-storage design is replaced by MariaDB’s own replication and clustering. The run asks you to test the workload on MariaDB before cutover. Pick the 10.11 line: as of November 2026, 10.6 is scheduled for decommissioning on 1 July 2027. | The application uses plain MySQL features and its data fits a MariaDB plan. |
| PostgreSQL Flex, for the openGauss-based edition | Schema, procedures and clients need a conversion and a test. A distributed layout becomes a managed PostgreSQL service; confirm that its data volume and throughput fit before you commit. | The workload mostly uses standard SQL and the team can own a conversion project. |
| The same engine on a STACKIT server | You keep the engine and operate it: backups, patching, failover and monitoring are yours. The run does not draft this. | A feature has no counterpart on MariaDB or PostgreSQL and removing it costs more than operating a database. |
| Split the workload | Move the part that is plain relational data to the managed target and keep the specialised part separate. A design task, not a mapping. | One GaussDB instance serves both transactions and heavy analytics. |
Check the engine versions and plans on STACKIT on the day you decide; they change.
Facts that drive the decision
MySQL: storage is decoupled
Huawei describes GaussDB(for MySQL) as compute and storage decoupled, with nodes sharing the underlying storage and up to 128 TB. MariaDB on STACKIT is sized by plan, so check the data volume against the plans first.
openGauss: related to PostgreSQL, not equal
Huawei’s FAQ on the relationship between GaussDB and PostgreSQL states that GaussDB began on the Postgres-XC architecture of PostgreSQL 9.2 and now uses only standard APIs and common functions of PostgreSQL. It also lists a thread pool, Ustore and distributed deployment as differences. The FAQ speaks of GaussDB in general and does not name openGauss; we apply it to the openGauss-based edition because the Huawei provider documents that edition as GaussDB (GaussDB OpenGauss instance management).
Distributed is the hard case
Huawei states that PostgreSQL supports only centralized deployment while GaussDB supports centralized and distributed. The demo instance asks for one shard and two coordinators across three zones; a managed PostgreSQL service is the nearest, not an equal.
Target versions have dates
As of November 2026: PostgreSQL Flex 14 reaches end of support on 12 November 2026, and its notes require version 15 or higher; versions 16 and 17 were announced as available. MariaDB 10.6 is scheduled for decommissioning on 1 July 2027.
A third GaussDB type the run cannot classify
Provider version 1.100.0 documents a further resource, huaweicloud_gaussdb_instance, described as GaussDB OpenGauss instance management. The run does not know this type. It classifies it MANUAL_REVIEW with LOW confidence and assesses and drafts nothing of it.
resource "huaweicloud_gaussdb_instance" "reporting" {
name = "reporting-gauss"
password = var.db_password
flavor = "gaussdb.opengauss.ee.dn.m6.2xlarge.8.in"
vpc_id = huaweicloud_vpc.main.id
subnet_id = huaweicloud_vpc_subnet.data.id
security_group_id = huaweicloud_networking_secgroup.db.id
availability_zone = "eu-west-101a,eu-west-101b,eu-west-101c"
sharding_num = 1
coordinator_num = 2
ha {
mode = "enterprise"
replication_mode = "sync"
consistency = "strong"
}
volume {
type = "ULTRAHIGH"
size = 40
}
}- **Source:** `huaweicloud_gaussdb_instance` — main.tf:67
- **Classification:** MANUAL_REVIEW · **Confidence:** LOW
- **Feasibility:** UNKNOWN — blocked by a point the scan could not establish
- **Why:** huaweicloud_gaussdb_instance is not in the knowledge base catalogue; an architect has to decide the target. Nothing of this resource is assessed or drafted (unknown source type).
- **Depends on:** `huaweicloud_networking_secgroup.db`, `huaweicloud_vpc.main`, `huaweicloud_vpc_subnet.data`Check your resource type
Search the Terraform for the three GaussDB type names before you read any result. A database declared with the third type is not in the targets of the run and needs the same decision from you.
It is not listed as stateful
The data-movement file lists the two catalogued instances only. An unknown type does not appear there, so do not treat that list as the inventory of your databases.
What the run leaves you for the two catalogued instances
Selected lines from the output folder. Left: the heading of each catalogued unit in engineering/architect-report.md and the line that names the settings it leaves to you (9 for the MySQL instance, 14 for the openGauss instance; the report lists the first five of each). Right: the data question the run records.
#### `huaweicloud_gaussdb_mysql_instance.orders`
- unclassified (9; FAILED 9): `backup_strategy.keep_days`, `backup_strategy.start_time`, `flavor`, `name`, `password` and 4 more
#### `huaweicloud_gaussdb_opengauss_instance.ledger`
- unclassified (14; FAILED 14): `availability_zone`, `coordinator_num`, `flavor`, `ha.consistency`, `ha.mode` and 9 more| Unit | Source service | Target service | Application | Mechanism | State | Data class | RPO | Downtime tolerance |
|---|---|---|---|---|---|---|---|---|
| huaweicloud_gaussdb_mysql_instance.orders | huaweicloud_gaussdb_mysql_instance | STACKIT MariaDB | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |
| huaweicloud_gaussdb_opengauss_instance.ledger | huaweicloud_gaussdb_opengauss_instance | STACKIT PostgreSQL Flex | | UNKNOWN | DECISION_REQUIRED | NOT_PROVIDED | NOT_PROVIDED | NOT_PROVIDED |How to decide, in five steps
1. Name the product behind every instance
Resource type, flavor prefix and engine version tell you which GaussDB you run. Do this first, because the target depends on it.
2. List what the application really uses
Procedures, functions, extensions, compatibility settings and driver versions. These, not the instance size, decide whether MariaDB or PostgreSQL Flex works.
3. Convert and test on a copy
Load a copy of the schema and a sample of data into the candidate target and run the application’s own test suite and its slowest queries.
4. Settle sizing and availability
Read replicas and HA modes of the source do not carry over. Decide replicas, failover and backup on the target from the recovery point the business states.
5. Record the data mechanism
The run records mechanism UNKNOWN and DECISION_REQUIRED. Choose dump and restore or a replication tool, and write down the downtime you accept.
Questions architects ask about GaussDB
Why does the run propose MariaDB and not MySQL?
The run states that STACKIT offers MariaDB, not MySQL, and that the workload must be tested there before cutover. STACKIT positions MariaDB as a route for migrating from MySQL.
Is GaussDB for openGauss the same as PostgreSQL?
No. Its SQL is related, but Huawei’s FAQ on GaussDB states that it uses only standard APIs and common functions of PostgreSQL and lists a thread pool model, Ustore and distributed deployment as differences. The run says schema, procedures and clients need a conversion and a test on PostgreSQL Flex.
Can StackToIT convert the schema?
No. It classifies and sequences; it writes no database conversion. The conversion is the project you plan.
What if our instance uses the third GaussDB resource type?
The run records it as MANUAL_REVIEW with LOW confidence and drafts nothing, so the target decision is entirely yours. Use the two catalogued results as a starting point for the discussion, not as a result for that instance.
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.