Before you begin
Superblocks Database is enabled per data plane and routed by exact data tag, so it is the last step in setting up a Hybrid deployment, not the first. Complete these before you continue.1
Decide your data plane layout and deploy each data plane
Most customers run two data planes, one for the
dev tag and one for the production tag, in separate AWS accounts and VPCs. See Plan your data planes and Reference architectures.2
Finalize your data tags and environments
Create every data tag you will enable databases for and decide which environments allow it on the Environments page. Each database-enabled data plane must serve exact tags; the default
profile:* is not allowed.3
Check the layout against the database rules
One database-enabled data plane per data tag, a separate prerequisite stack per region, and no wildcard tags. See Data planes and Superblocks Database.
Setup decisions and prerequisites
Superblocks Database requires a Hybrid or Cloud-Prem deployment on AWS, running on ECS Fargate or EKS. It is not available on Superblocks Cloud. If you are using Cloud-Prem with Superblocks-managed data planes, talk to your account manager. Decisions you cannot change later. Choose these per data plane before your firstterraform apply:
- Agent name. A permanent identifier for the data plane, for example
produsw2, used as the prefix for its AWS resources. At most 15 lowercase alphanumeric characters, unique per AWS account. - Data tags. The exact tags this data plane serves. They are declared twice, as a list of bare keys in Terraform (
agent_tags = ["production"]) and as aprofile:string on the data plane (profile:production), and the two must match. Neither accepts*. - VPC. Every IAM policy for the data plane is scoped to one VPC, which needs private subnets in at least two Availability Zones.
- Capacity shape. Two instances at 2-32 ACUs each for every data tag, including edit and preview. This is the module default, but set it explicitly. Every cluster the pool adds later inherits whatever shape is configured at the time, so decide before the first cluster is created. See Reference: Cluster autoscaling.
- Terraform 1.6 or later. Superblocks distributes a module that creates the IAM roles and OpenTofu state bucket. Manual setup is not recommended.
- Permission to create IAM roles, an S3 bucket, and Aurora clusters. See Reference: Raw IAM policy JSON if your organization requires policies to be pre-approved.
- AWS quota headroom for Aurora clusters and instances, DB subnet groups, security groups, ENIs, and free IP addresses in your database subnets. The pool grows over time.
- Data plane image v1.49.0 or later. On Fargate, pin
superblocks_agent_image = "ghcr.io/superblocksteam/agent:v1.49.0". On EKS, use a chartappVersionthat deploys agentv1.49.0or newer.
One-time setup
Setup runs once per data plane: create the AWS prerequisites with Terraform, provision the first Aurora cluster from the admin panel, and confirm builders can use it. After that, Superblocks grows and manages the pool without further setup.Values to gather
Collect these values first. Replace every<PLACEHOLDER> in the examples with your own values. <AGENT_NAME>, <DATA_TAG_*>, and <VPC_ID> are the fixed values from Setup decisions above.
Step 1: Run the Terraform module
Superblocks publishes two submodules as part of thesuperblocksteam/superblocks/aws Terraform registry module. Use a compatible release from version 1.5.3 up to, but not including, 2.0.0 so the prerequisite stack includes the App Database modules, observability IAM resources, current resource-naming inputs, and the tagged security-group-rule permissions the current physical modules need. A 1.5.2 stack can fail provisioning with AccessDenied when the worker creates those rule resources:
modules/app-db-prereqs: run by all customers. Creates the lifecycle worker IAM roles, connector IAM roles, shared Enhanced Monitoring role, and shared S3 state bucket.modules/app-db: ECS Fargate only. Takes the prereq outputs plus your database config and renders the data plane runtime configuration asecs_env_vars, ready to inject into the ECS task definition. It also outputssuperblocks_agent_tagsin the form the data plane expects, so the profiles it serves come from the same place as the databases it provisions.
ECS Fargate
ECS Fargate
For Fargate deployments, both modules are run together. The The
modules/app-db outputs (ecs_env_vars and superblocks_agent_tags) are passed directly into the root terraform_aws_superblocks module, which wires them into the ECS task definition. You do not need to inspect the contents of ecs_env_vars; it is generated in the expected format.Step 1a: Add both modules to your Terraform config.The snippet below sets the required inputs and the recommended database settings. Every option is catalogued on the reference page: Module options and Per-data-plane options for the prerequisite stack, Pool options and Physical database options for the database settings.deployment block above is the recommended shape for every data tag. It matches the module default, but set it explicitly rather than relying on the default. Setting min_acu to 0 lets an idle cluster pause, which costs less but adds a cold start to the next connection (not recommended). See Reference: Cluster autoscaling.Step 1b: Run terraform apply. The module applies three changes: it creates the prereq resources (IAM roles and S3), renders the data plane runtime config as env vars, and wires them into the ECS task definition along with the lifecycle worker task role.Step 1c: ECS redeploys automatically when the task definition is updated. Your data plane starts with Superblocks Database enabled and registers its database lifecycle capability with the Superblocks control plane.To run more than one data plane in this account and region, see Reference: Multiple data planes in one account and region.EKS
EKS
For EKS deployments, the Terraform module handles IAM and S3 only. The database configuration is set separately in your Helm chart under the If that command prints nothing, create the IAM OIDC provider for the cluster before continuing (see AWS: Create an IAM OIDC provider for your cluster).You can also confirm in the console: copy the OpenID Connect provider URL from EKS → Clusters → your cluster → Overview → Details, strip the If your data plane pod uses a namespace or service account other than the chart defaults, or already has an IRSA-annotated role, set The Your data plane restarts with Superblocks Database enabled and registers its database lifecycle capability with the Superblocks control plane.To run more than one data plane in this account and region, see Reference: Multiple data planes in one account and region.
databaseLifecycle block.EKS-only prerequisite: OIDC provider ARN
In addition to the values to gather above, EKS needs the cluster’s IAM OIDC identity provider ARN (<OIDC_PROVIDER_ARN>). It is required for IRSA so the data plane pod can assume the lifecycle worker role.Every EKS cluster exposes an OIDC issuer URL. Separately, your AWS account must have an IAM OIDC provider for that issuer — that provider’s ARN is what you pass to Terraform. Retrieve it with:https:// prefix, then search for that value under IAM → Identity providers. Open the matching provider — its ARN is at the top of the page.Step 1a: Run the prereqs module and apply.The snippet below sets the required inputs, including the EKS-only oidc_provider_arn. Every optional input is catalogued in Reference: Module options and Reference: Per-data-plane options.namespace, service_account_name, or existing_role_name as described in Reference: Per-data-plane options.Step 1b: Wire the outputs into your Helm values. After terraform apply, add the module outputs and your database config to your Helm values. The settings span four top-level sections, not just databaseLifecycle. The two IAM roles in particular are wired through the sections that already own identity in the chart:deployment values above are the recommended shape for every data tag. They match the module default, but set them explicitly rather than relying on the default. Setting min_acu to 0 lets an idle cluster pause, which costs less but adds a cold start to the next connection (not recommended). See Reference: Cluster autoscaling.Every database setting is catalogued in Reference: Pool options and Reference: Physical database options, including the Helm-only switches for CloudWatch log exports and Performance Insights described under Observing.Values not shown keep their chart defaults, which are the recommended settings:- The logical and physical database modules default to the modules packaged in the data plane image (
./modules/postgres-managed-databaseand./modules/aws-aurora-managed-cluster). OverridedatabaseLifecycle.modules.logical.sourceordatabaseLifecycle.modules.physical.sourceonly to run a fork, a custom module, a git pin, or standalone RDS (./modules/aws-rds-managed-instance). Keep both sources on compatible releases. Settingallocated_storageandinstance_classwithout changingmodules.physical.sourcestill runs the Aurora module. - TLS uses
verify-fullagainst the AWS trust bundle packaged in the data plane image. The chart refuses to enable Superblocks Database with any weaker mode. - The OpenTofu working directory and binary path are fixed properties of that image. The chart rejects attempts to override either.
- The resource types the lifecycle worker may create default to exactly what the database modules it ships with declare. Set
allowedResourceTypesonly to run a fork or a custom module. A non-empty list replaces the default outright rather than adding to it.
Step 2: Provision your database from the admin panel
Once the data plane is running with Superblocks Database enabled, return to the data plane setup wizard, or open the Superblocks admin panel and navigate to Databases. You will see the database configuration registered by your data plane, including the engine, capacity settings, and data tags pulled from its running configuration. These are read-only: they reflect what you configured in Terraform or Helm. Click Provision. Superblocks dispatches the request to your data plane, which runstofu apply in your AWS account. You do not re-enter any configuration; it is already in the data plane.
Provisioning an Aurora cluster typically takes 5 to 15 minutes. The admin panel shows live status and updates automatically, so you do not need to keep the browser open.
If two admins click Provision at the same time, only one request proceeds. The second admin sees that provisioning is already in progress and when it started, and can follow the same live status.
When provisioning completes, the data plane sends a confirmation to the Superblocks control plane and the panel shows a success state. If provisioning fails, you see the error detail and a retry option. Failures are surfaced here, not to end users.
Step 3: Ready
Once the panel shows a success state, your builders can create apps backed by Superblocks Database immediately. There is no cold-start wait, because the database pool is already running.- Builders get an isolated logical database inside the shared pool on demand. When the pool is full, Superblocks provisions another cluster first, which takes 5 to 15 minutes. See Reference: Creating an app database.
- Deploys are gated. Superblocks blocks a deploy if the deploy-time database or its required SQL migrations are not ready.
Step 4: Verify observability
Open the newly provisioned cluster in the AWS RDS console and confirm that its settings match the options you selected:- CloudWatch Logs exports includes
postgresql, with a corresponding/aws/rds/cluster/<cluster-id>/postgresqllog group retained for 30 days. EKS deployments may show no export if you explicitly disabled it; Fargate deployments must show it. - Database Insights is in Standard mode, with Performance Insights enabled and retained for 7 days. EKS deployments may show it disabled if you explicitly opted out; Fargate deployments must show it enabled.
- Enhanced Monitoring is enabled at a 60-second interval, unless you disabled it.
Apply configuration changes to existing clusters
terraform apply and helm upgrade update the data plane’s advertised settings. They do not run OpenTofu against Aurora.
After the data plane registers, Superblocks compares those settings to each cluster’s last-applied configuration. If they differ, it queues an apply against the existing OpenTofu state, one cluster at a time. Superblocks refuses plans that would replace or destroy a cluster.
Use the admin Databases page when you need to start or resume that apply yourself. Confirm each action in the dialog.
Some settings cannot change on an existing pool: VPC, subnet list, subnet-group identity, Aurora parameter-group identity or family, and deployment mode (
serverless_v2 vs provisioned). Superblocks still queues an apply, then the data plane refuses it with policy_blocked and names the frozen field, for example subnet_ids or vpc_id. Revert that Terraform or Helm value. After the data plane registers the restored configuration, Superblocks queues a new apply across the clusters from the failed run. The old failed run is superseded and no longer offers Retry apply.
Backup retention, monitoring, tags, and serverless scaling (ACU range and instance count) can still change on existing clusters.
If connected data plane replicas advertise different configurations, Superblocks does not auto-queue an apply, and Apply settings and Force apply stay unavailable until the replicas agree. Wait for the rollout to finish.
You own the AWS resources
Every resource lives in your account, and AWS bills you directly for it. The Superblocks defaults balance cost and performance for most customers. Pool growth is automatic. Superblocks adds another cluster when the current one fills tomax_databases, or, on Helm, when remaining capacity hits minAvailableCapacityPercent. Your spend grows with usage without another terraform apply. The capacity and pool settings from Step 1 (ACU range, instance_count, max_databases, and on Helm minAvailableCapacityPercent) determine what that growth costs. The admin Databases page shows current pool state and capacity.
Every cluster the pool adds later inherits the capacity shape in your configuration at the time it is provisioned. When the data plane registers changes to supported physical settings, Superblocks automatically queues updates for existing clusters; see Apply configuration changes to existing clusters. Settle the frozen fields listed there (VPC, subnet list, subnet-group identity, Aurora parameter-group identity or family, and deployment mode) before the first cluster is created. Those cannot change on an existing pool.
Protect the OpenTofu state bucket
The state bucket is how Superblocks tracks what it created so it can later modify, resize, or retire those resources. Superblocks does not retain a copy; the bucket in your account is the only copy. If the state is lost, Superblocks can no longer manage the existing databases and recovery is a manual exercise.- Leave versioning enabled and leave the non-current version expiration alone.
- Do not rename, move, or re-encrypt the bucket, and do not manage it with another tool.
- Do not add lifecycle rules that expire current object versions.
Do not manage the tagged resources by hand
Editing or deleting the taggedsb-* clusters, subnet groups, or security groups directly in the AWS console creates drift. Console edits do not change the data plane’s advertised configuration, so they are not applied automatically. Use Force apply on the admin Databases page to restore the configured state, and route future changes through Terraform or Helm.
Keep the data plane current
The data plane image contains the lifecycle worker and the database modules it applies. Fixes, new engine options, and configuration changes ship with data plane releases, so a data plane that is not upgraded falls behind on both. See Upgrading the data plane.What Superblocks does, and what stays yours
Superblocks creates, configures, scales, and retires the Aurora clusters and the per-app logical databases, and runs your applications’ SQL migrations. Superblocks does not:- Patch or upgrade the database engine. AWS applies engine patches during the maintenance window you configure. Because applications share a cluster, a patch or failover affects every application on that cluster. Running a second instance (
instance_count = 2) reduces the impact but does not remove it. - Restore your data. Automated backups are configured from your
backup_retention_period, but performing a point-in-time restore or a snapshot restore is an operation you run in AWS. - Tune PostgreSQL for your workload, or manage database grants beyond the roles it creates for each application.
- Monitor the database on your behalf. Superblocks enables the observability signals described above, but the metrics and logs stay in your AWS account. Your organization owns access, dashboards, alarms, and incident response.

