Database migration to STACKIT: architecture and compatibility

A Multi-AZ PostgreSQL instance, converted

A small estate written for this page and assessed by StackToIT on 4 November 2026. Left: the RDS instance of the input. Right: the PostgreSQL Flex instance the engine wrote (the review comments above the block in the file are left out).

resource "aws_db_instance" "ledger" {
  identifier              = "ledger-pg"
  engine                  = "postgres"
  engine_version          = "16.4"
  instance_class          = "db.m6g.xlarge"
  allocated_storage       = 300
  multi_az                = true
  username                = "ledger"
  password                = var.db_password
  db_subnet_group_name    = aws_db_subnet_group.data.name
  backup_retention_period = 14
}

resource "stackit_postgresflex_instance" "ledger" {
  project_id = var.project_id
  name       = "ledger-pg"
  version    = "16"
  flavor_id  = "4.32-replica"
  storage = {
    class = var.postgresflex_storage_class
    size  = 323
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl          = var.ledger_allowed_cidrs
    access_scope = var.ledger_access_scope == "SNA" ? "SNA" : null
  }
  retention_days = 32
}

• Multi-AZ becomes a replica flavor

  The 4 vCPU and 16 GiB class with a standby becomes 4.32-replica, 4 vCPU and 32 GiB, the smallest high-availability flavor that covers it in the eu01 catalogue the run read. The draft does not claim how a failover behaves; no STACKIT page the run read states it.

• Storage rounds up

  300 GiB becomes 323. STACKIT states the size only as gigabytes, so the draft converts at 10^9 bytes per GB and rounds up, never to less than the source.

• Retention and access change

  14 days of backups become retention_days 32, marked TRANSFORMED. The access list is a variable with no default, because the source is not proven public and the STACKIT endpoint is reached through an access list.

A key-value table, redesigned

From the same run. DynamoDB has no counterpart, so the run classifies the table REDESIGN and drafts one alternative, a MongoDB Flex instance for the tables of the estate.

resource "aws_dynamodb_table" "carts" {
  name         = "carts"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "cart_id"

  attribute {
    name = "cart_id"
    type = "S"
  }

  ttl {
    attribute_name = "expires_at"
    enabled        = true
  }
}

resource "stackit_mongodbflex_instance" "dynamodb_tables" {
  project_id = var.project_id
  name       = "dynamodb-tables"
  acl        = var.dynamodb_tables_allowed_cidrs
  version    = var.dynamodb_tables_version
  flavor = {
    cpu = var.dynamodb_tables_cpu
    ram = var.dynamodb_tables_ram
  }
  replicas = 3
  storage = {
    class = var.mongodbflex_storage_class
    size  = var.dynamodb_tables_storage_gb
  }
  backup_schedule = "0 2 * * *"
  options = {
    type                       = "Replica"
    point_in_time_window_hours = var.dynamodb_tables_pitr_hours
  }
}

• An alternative, not an equivalent

  The run says so in its reason: key design, capacity modes and conditional writes do not carry over. PostgreSQL Flex with JSONB columns is the other option.

• Application work, not data work

  The review lines ask for the data access layer to be rewritten against the MongoDB API, and for the instance to be sized from data volume and request load, since capacity units do not translate.

Engine by engine: target and class

One row per data store of the run, all MEDIUM confidence, plus the Oracle Database system from the Oracle Cloud run of our source comparison.

Classes and tests are the run's own, taken from assessment.json. As of November 2026, the MariaDB page of STACKIT states that version 10.6 is deprecated and scheduled for decommissioning on 1 July 2027, and asks for 10.11 or newer by that date.

What the draft changes on every instance

Rows are drawn from the not-carried, recovery and ledger comments in terraform/data.tf, with the MariaDB backup cadence and the PostgreSQL Flex clone behaviour checked against the STACKIT documentation listed below.

How the data moves

The run lists six stateful units in migration/data-movement.md. For each it states that no method is chosen, because size, tolerated downtime and consistency are not in the source.

1. 01

   Choose a method per unit

   For PostgreSQL the plan holds typed steps for dump and restore, logical replication, or a tool of your own. For SQL Server the handover describes a native backup of each database on RDS, a copy of the .bak files into a STACKIT bucket and an import into SQLServer Flex; the SQLServer Flex feature page says a restore goes only to a new database.

2. 02

   Rehearse and time it

   A preflight step closes open checks (versions, extensions, roles, network); a rehearsal moves a copy into a scratch database and records timings. The freeze window comes from those timings.

3. 03

   Freeze, sync, reconcile

   Writers are stopped, a final sync runs, and counts, checksums and one application query are compared. The result is a recorded GO or NO-GO. On NO-GO the clients still point at the untouched source.

4. 04

   Switch the connection

   Clients change host, port, database name and credentials. Where no resource of the source references a database, the plan notes that the applications are outside the source and their owners list them.

5. 05

   Keep the way back

   Cleanup steps wait for the rollback decision. After them the way back is the final snapshot of the source, and the plan marks the decommission of the database as not reversible.

Decisions the architect owns

• Engine for MySQL and Redis estates

  MariaDB for MySQL, Valkey for Redis: a compatibility test decides, not the class.

• Document or relational for DynamoDB

  MongoDB Flex or PostgreSQL Flex with JSONB; both rewrite the access layer.

• Exposure of each endpoint

  Access-list CIDRs, or a Network Area scope where your account has it.

• High availability level

  Single node or replica flavor, from the recovery objectives, not from the source class alone.

• Oracle Database

  A new engine with conversion, or self-managed Oracle under your own licence.

• Data-movement method and window

  One open decision in decisions.json covers all six stateful units, with one member per unit; answer it unit by unit.

• SQL Server licence

  The run records that the STACKIT pages it read state no licence terms for SQLServer Flex; settle licence-included or own licence in the contract.

Questions database teams ask

Sources

• STACKIT SQLServer Flex: supported and unsupported features
• STACKIT PostgreSQL Flex overview
• STACKIT MariaDB overview
• Backup and clone of STACKIT PostgreSQL Flex
• STACKIT MariaDB backup and restore