OCI Database with PostgreSQL to PostgreSQL Flex

Step 1: the input and what StackToIT records for it

A four-resource Oracle Cloud estate written for this page and assessed by StackToIT on 4 November 2026: a VCN, a subnet, a network security group and one PostgreSQL system of two nodes. Left: the database block of the input, unchanged. Right: the decision recorded for it in assessment.json. 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.

resource "oci_psql_db_system" "orders" {
  compartment_id              = var.compartment_id
  display_name                = "orders-db"
  db_version                  = "16"
  shape                       = "VM.Standard.E4.Flex"
  instance_count              = 2
  instance_ocpu_count         = 4
  instance_memory_size_in_gbs = 64

  network_details {
    subnet_id = oci_core_subnet.data.id
    nsg_ids   = [oci_core_network_security_group.db.id]
  }

  storage_details {
    is_regionally_durable = true
    system_type           = "OCI_OPTIMIZED_STORAGE"
    iops                  = 75000
  }

  credentials {
    username = "orders_admin"
    password_details {
      password_type  = "VAULT_SECRET"
      secret_id      = var.db_secret_id
      secret_version = "1"
    }
  }

  management_policy {
    maintenance_window_start = "sun 02:00"
    backup_policy {
      kind           = "DAILY"
      backup_start   = "01:00"
      retention_days = 35
    }
    pitr_policy {
      kind         = "STANDARD"
      restore_days = 7
    }
  }
}

{
  "id": "oci_psql_db_system.orders",
  "result": {
    "class": "REPLATFORM",
    "confidence": "MEDIUM",
    "target": {
      "service": "STACKIT PostgreSQL Flex",
      "resources": [
        "stackit_postgresflex_instance",
        "stackit_postgresflex_database",
        "stackit_postgresflex_user"
      ]
    },
    "reason": "Managed PostgreSQL to managed PostgreSQL: data moves with pg_dump/pg_restore or logical replication, and the shape becomes a Flex flavor."
  }
}

• REPLATFORM, medium confidence

  Managed PostgreSQL goes to managed PostgreSQL, so the platform model changes while the engine stays. The run caps confidence at medium because the oci provider has no lock file entry: the version a plan would use is not proven. Commit .terraform.lock.hcl next to the root module and the cap goes away.

• Three STACKIT objects

  The target is STACKIT PostgreSQL Flex, written as stackit_postgresflex_instance, stackit_postgresflex_database and stackit_postgresflex_user. The run lists PostgreSQL Flex in the STACKIT catalogue snapshot for both eu01 and eu02.

• Nothing is drafted for you

  The Terraform folder of this run holds only provider and variable files. For an Oracle Cloud source every unit, this database included, is left to your architects, and the manual steps for it sit in execution/manual/actions.md.

• 19 settings named

  engineering/architect-report.md counts them for this unit and names the first five; assessment.json lists all 19: compartment_id, credentials, db_version, display_name, instance_count, instance_memory_size_in_gbs, instance_ocpu_count, shape, the network subnet and security groups, the storage settings and six management_policy settings for backups, point-in-time recovery and the maintenance window.

Step 2: the order the run proposes

The command, run from inside the demo's input folder, writes the result to the output folder next to it, with the options the run for this page used. With OpenTofu on the PATH, the provider packages in a local mirror and a .terraform.lock.hcl in the source, you can leave out --no-validate and let the run also validate the source with OpenTofu. The sequencing file puts the units in waves from their dependencies.

# run from inside the demo's input folder; the output folder sits next to it
stacktoit assess . ../out --offline --no-validate

## Wave 1 — 1 unit(s)

| Unit | Class | Target |
|---|---|---|
| `oci_core_vcn.main` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 2 — 2 unit(s)

| Unit | Class | Target |
|---|---|---|
| `oci_core_network_security_group.db` | RECONFIGURE / MEDIUM | STACKIT security groups |
| `oci_core_subnet.data` | RECONFIGURE / MEDIUM | STACKIT network |

## Wave 3 — 1 unit(s)

| Unit | Class | Target |
|---|---|---|
| `oci_psql_db_system.orders` | REPLATFORM / MEDIUM | STACKIT PostgreSQL Flex |

• Network before data

  The database sits in wave 3 because it depends on the subnet and the security group, which depend on the VCN. Your STACKIT network and security group must exist before the instance can be reached.

• The data decision stays open

  migration/data-movement.md lists the system as a stateful unit with the mechanism UNKNOWN and the state DECISION_REQUIRED. The size of the data, its change rate and the downtime your business tolerates are not in the Terraform, so the run does not guess them.

Step 3: what to change before you apply

Each row takes one setting of the demo input and says what STACKIT asks for in its place. Values on the STACKIT side come from the STACKIT documentation and the STACKIT Terraform provider 0.121.0; check them again on the day you build.

Maintenance window: the demo sets sun 02:00. The STACKIT pages used here do not state how a window is set, so confirm it in the PostgreSQL Flex documentation instead of assuming an equivalent.

Step 4: move the data

StackToIT never moves data. These steps are general practice for a PostgreSQL to PostgreSQL move; the engine names the two mechanisms in its reason and leaves the choice to you.

1. 01

   Create the target first

   Apply your reviewed instance, database and user on STACKIT. Check that the extensions your application uses are among the 33 listed for PostgreSQL Flex, for example pgvector, postgis or pg_trgm.

2. 02

   Choose dump or replication

   For a database that tolerates a maintenance window, a dump is the simple path: for example pg_dump -Fd -j 4 on the source and pg_restore -j 4 on the target. If the window is short, plan logical replication instead, and confirm on STACKIT that the instance accepts it before you rely on it; this page does not claim that.

3. 03

   Rehearse and time it

   Restore into a throwaway instance and measure the duration with your real data volume. The run cannot, because the size of the data is not in the source.

4. 04

   Cut over

   Stop writes on the source, take the final dump or let replication drain, restore, run your validation queries and point the application at the new host and port. Keep the OCI system untouched until the checks pass; that is your rollback.

5. 05

   Set up backups and an owner

   Confirm the first daily backup on STACKIT exists, and test a clone once. Create the database users your applications need, one per login, and hand the credentials to their owners through your secret store.

Decisions your architects own

• One node or three

  Availability on STACKIT is a choice of instance type made at creation, not an OCI node count carried over.

• Flavor and performance class

  The performance class is fixed after creation, so size it with headroom. Storage size can be increased later.

• Dump or replication

  The trade is downtime against moving parts. The data-movement file stays open until you record the choice.

• Network exposure

  Which address ranges may reach the database. Decide this on purpose and write it as ACL entries; the default is the predefined STACKIT ranges only.

• Backup retention

  32 to 90 days on STACKIT. Pick a number that matches your recovery requirement.

• Who owns the secrets

  Decide where database credentials live before the first user is created.

Questions database teams ask

Sources

• oci_psql_db_system resource, oracle/oci provider 9.11.0
• stackit_postgresflex_instance resource, STACKIT provider 0.121.0
• STACKIT PostgreSQL Flex: flavors and performance classes
• STACKIT PostgreSQL Flex: architecture
• STACKIT PostgreSQL Flex: backup and clone
• STACKIT PostgreSQL Flex: supported extensions