Database & migrations

A real database, with every schema change tracked in code.

Your app's data lives in a real database, and the shape of that data — which tables exist, what they store — changes as your product grows. In Pikku Studio Cloud, every one of those changes is a migration: a small file in your code that says exactly what changed. Nothing about your database's structure is ever edited by hand in a dashboard.

Labeled diagram: a stack of numbered migration files ("001 create users", "002 add orders", "003 add order status") with an arrow into a database cylinder. Caption: "The schema is the sum of its migrations — every change on record, applied in order."

Why migrations in code matter

A database edited through a dashboard has no memory — nobody can say what changed, when, or why, and no two environments end up quite the same. Migrations fix that:

  • Every change is on record. The history of your schema is readable, reviewable, and versioned with the rest of your code.
  • Every environment matches. The same migrations run in order on your test stage and your production stage, so what you tested is what you ship.
  • Changes ride along with deploys. When a new version of your app needs a new table, the migration applies as part of the deployment — the code and the schema move together.

You don't write them by hand

When you tell the builder your product needs to track something new, Pikku Studio Cloud writes the migration for you — you'll see it as part of what changed, like any other code. The point isn't that you author migrations; it's that the record exists, so your database is never in a state nobody can explain.

Schema changes are code, so they pass through the same checks as everything else — reviewed in the plan, applied in order, identical on every stage.

Seeing the result

To look at what your database actually stores — the tables and how they connect — use the read-only schema viewer in observability.

Where to go next