Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.superblocks.com/llms.txt

Use this file to discover all available pages before exploring further.

​
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 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 are provisioned on your own backend — AWS RDS, Databricks LakeBase, or Snowflake — inside your VPC. Superblocks orchestrates the provisioning but your data stays on your infrastructure.
  • Dev and production are separated by default. Builders who have never managed a database do not need to understand environments. Superblocks automatically creates separate development and production databases and handles schema migrations on deploy. Test data never reaches production.

​
Supported backends

BackendDescription
AWS RDSManaged PostgreSQL on Amazon RDS
Databricks LakeBaseManaged Postgres-compatible database on the Databricks Lakehouse
SnowflakeManaged database on Snowflake
Administrators select a default backend for the organization. When a builder asks Clark for any feature that requires persistence for their app, the platform provisions a new database on your configured backend.

​
How it works

​
1. Admin configures the default backend

In Organization Settings, administrators connect their database backend and set it as the default for all new apps. This is a one-time setup. The database provisioning is triggered from your data plane via code that you control.

​
2. Clark provisions a development 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. Database branching separates dev from production

Every app gets separate development and production databases. Builders work against the development database while editing, so test data never touches production. This separation is automatic. Builders do not need to configure it.

​
4. Schema migrations run on deploy

When a builder publishes their app, Superblocks automatically:
  • Provisions the production database (if it does not already exist)
  • Applies schema migrations from development
  • Deploys a clean production schema with no test data
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.