Skip to main content

​
Overview

Nearly every app built with AI needs a database. The moment a builder asks Clark to “track requests,” “store approvals,” or “save user preferences,” that app needs persistent storage. Without a native database, this creates a problem: either IT provisions and manages databases manually for every app — which does not scale when hundreds of builders are vibe coding — or builders are forced to use external storage that moves data outside your network, and manage the databases themselves. Superblocks Database solves both problems:
  • Every app gets its own Aurora PostgreSQL database automatically. Builders describe what they need, and Clark provisions an isolated database on your infrastructure. No tickets, no manual setup, no database expertise required.
  • Data never leaves your network. Databases run on AWS Aurora PostgreSQL inside your own VPC. Superblocks orchestrates the provisioning but your data stays on your infrastructure.
  • Development and production are separated by default. Builders who have never managed a database do not need to understand environments. Each app gets a separate database per environment, and Superblocks handles schema migrations on deploy. Test data never reaches production.
Each app gets its own isolated database, and those databases are hosted on shared Aurora PostgreSQL clusters that your admins size. Pooling many apps onto a cluster is what keeps the cost predictable — the default is 100 apps per cluster, and Superblocks adds another cluster as the pool fills. When a builder asks Clark for any feature that requires persistence, the platform creates that app’s database automatically.

​
How it works

​
1. Your admins turn it on once

Enabling Superblocks Database is an infrastructure change, not a settings toggle. Your admins run a Terraform module in your AWS account to create the IAM roles and the state bucket, add the database configuration to the data plane (as ECS task environment variables or Helm values), and then provision the first Aurora cluster once from the Superblocks admin panel. From then on, the admin panel shows that configuration read-only, because it reflects what the running data plane is actually configured with. Every database operation after that is triggered from your data plane, running code you control. See Setup for the full walkthrough and the exact AWS permissions involved.

​
2. Clark provisions a development Aurora PostgreSQL database

When a builder asks Clark to store data — for example, “add a database to track commission rate requests”:
  • Clark tells your data plane to provision a database
  • Your data plane provisions an isolated development database for that app (via code you control)
  • Clark proposes the schema (tables, columns, indexes) for the database and runs these migrations through your data plane
  • Clark wires up the APIs to read and write data
The builder never leaves the Superblocks editor. They describe the feature, and Clark handles provisioning and schema design.

​
3. Each environment gets its own database

Development and production are separate databases, not two views of one. Builders work against the development database while editing, so test data has no path into production. Databases are organized the way your data planes are: in the common setup where staging and production run separate data planes, each app gets one isolated database per environment. This separation is automatic. Builders do not need to configure it.

​
4. Schema migrations run on deploy

Clark keeps the schema in the application’s own code as .sql migration files, so the schema is versioned alongside the app. When a builder publishes, Superblocks automatically:
  • Creates the production database if it does not already exist
  • Applies the app’s migrations to it, producing the same schema with none of the development data
  • Blocks the deploy until the production database and its migrations are ready
There is no manual migration step. The platform handles the full lifecycle from development through production.

​
What builders experience

From the builder’s perspective, database provisioning is invisible. They prompt Clark to add a feature that needs persistent data, and Clark creates the database, writes the schema, and builds the APIs. When they publish, the production database is ready with a clean schema. This gives every builder a persistent data store for their app, backed by your organization’s infrastructure.