Google Cloud vs STACKIT: service mapping

The twelve resources of the run

An estate written for this page: a network with one subnetwork, a firewall rule and a virtual machine, plus Cloud SQL for PostgreSQL, a bucket, Memorystore, a Pub/Sub topic, a secret, a DNS zone, Bigtable and a BigQuery dataset. StackToIT assessed it on 4 November 2026. Classes are as the run decided them.

The run counted 1 DIRECT, 7 RECONFIGURE, 2 REPLATFORM and 2 REDESIGN. Wave 1 holds nine units with no dependency, wave 2 the subnetwork and firewall rule, wave 3 the virtual machine. All twelve carry at most MEDIUM confidence: no lock file pins the Google provider, and the run says the version a plan would use is not proven.

Three data services, converted

The same run. First pane: the three data blocks of the input, in file order (main.tf lines 56 to 79). Then one pane per STACKIT resource block the engine wrote, from terraform/data.tf and terraform/storage.tf, without the review comments above each block. Plan names, versions and access lists remain variables because the source states none of them for the target.

resource "google_sql_database_instance" "main" {
  name             = "shop-db"
  region           = "europe-west3"
  database_version = "POSTGRES_16"

  settings {
    tier = "db-custom-4-15360"
  }

  deletion_protection = true
}

resource "google_storage_bucket" "media" {
  name                        = "shop-platform-prod-media"
  location                    = "EUROPE-WEST3"
  uniform_bucket_level_access = true
}

resource "google_redis_instance" "cache" {
  name           = "shop-cache"
  tier           = "STANDARD_HA"
  memory_size_gb = 4
  region         = "europe-west3"
}

resource "stackit_valkey_instance" "cache" {
  project_id = var.project_id
  name       = "shop-cache"
  plan_name  = var.cache_plan_name
  version    = var.cache_version
  parameters = {
    sgw_acl = join(",", var.cache_allowed_cidrs)
  }
}

resource "stackit_postgresflex_instance" "main" {
  project_id = var.project_id
  name       = "shop-db"
  version    = "16"
  flavor_id  = "4.32"
  storage = {
    class = var.postgresflex_storage_class
    size  = 20
  }
  backup_schedule = "0 2 * * *"
  network = {
    acl = var.main_allowed_cidrs
  }
  retention_days = 32
}

resource "stackit_objectstorage_bucket" "media" {
  project_id = var.project_id
  name       = "shop-platform-prod-media"
}

• Values to confirm

  The database tier db-custom-4-15360 (4 vCPU, 15 GiB) became flavor_id 4.32, which the draft explains as 4 vCPU and 32 GiB, the smallest single-node PostgreSQL Flex flavor in eu01 that covers the source. The draft also sets a daily 02:00 backup and 32 days of retention, which its comments call a default and the STACKIT minimum, because the source states neither. The Valkey access list has no default and the draft rejects an empty list, so you must name the client ranges. Confirm all of these before you plan.

Further services in the curated mapping

Services this run did not contain. They come from the mapping StackToIT keeps for Google Cloud, not from this run, so treat the class as the usual one, not as a result.

Memorystore is RECONFIGURE in this run; the curated mapping allows REPLATFORM as well, depending on the configuration.

Configuration differences that bite in practice

The first seven rows come from findings and draft comments this run raised on the estate. The two DNS rows come from the Cloud DNS run behind our DNS cutover runbook and from the STACKIT DNS documentation, because this estate has an unsigned public zone and no private zone.

How to read the mapping

• The class is the type of work

  RECONFIGURE means a counterpart exists and settings change. REPLATFORM means a different platform model. REDESIGN means the architecture changes. No class is an approval on its own.

• Read the open settings, not only the class

  A DIRECT zone still leaves the switch of the registrar's name servers to you, and a REPLATFORM topic leaves its names and delivery settings open. The class and the open decisions are two different answers.

• Start with the REDESIGN rows

  They have no counterpart, so they set the schedule and the budget. Waves follow dependencies only: Bigtable and BigQuery sit in wave 1 because nothing in this estate depends on them, not because the run ranks them first. Start their design work before the other units, whatever wave they are in.

• Pin the provider before you trust the confidence

  The run states that units of a provider with no lock file entry are capped at MEDIUM confidence. Commit the lock file that pins the Google provider and run again; a unit that is still MEDIUM after that is MEDIUM on its own terms.

Questions architects ask

Sources

• STACKIT documentation: RabbitMQ
• STACKIT documentation: DNS product overview
• STACKIT documentation: MongoDB Flex
• Google Cloud documentation: Pub/Sub subscriptions
• Google Cloud documentation: Bigtable overview
• Google Cloud documentation: Cloud DNS zones