Schema Changes, Migrations, and Target Strategy
Understand the full Database Manager workflow from schema design to migrations, target strategy, and publish-time database updates.
Introduction
Use this tour when you need the complete Database Manager story instead of only a single table action. The goal is to connect schema design, relation choices, Apply Database Changes, migration files, environment strategy, and publish-time database updates into one practical workflow.
Start with the development database you actually control
Database Manager work should start on a development target, not directly on the live production schema. Create the table, field, and relation changes where you can still revise them safely, then let the rest of the stack catch up around that schema before you ever publish it outward.
Create tables and add fields deliberately
Start with the smallest table shape that truly represents the records you need. Create the table, add the fields you know are required, and name them as if future queries, forms, and server actions will depend on them, because they will. The cleaner the structure is here, the less friction you create later in Query Builder, form binding, validation, and update actions.
Choose the right relation shape before you apply anything
This is the key modeling decision point. Use a normal reference when one record points to one parent, a sub table when a parent owns a nested child collection, and a multi reference when both sides can have many links. Making that choice before you apply changes is what keeps the later schema, queries, and editing flows understandable instead of patched together.
Apply Database Changes turns your design into tracked schema changes
The Apply Database Changes button is the deliberate handoff from design intent to executable schema history. Use it after the table, field, and relation changes make sense together. The point is not just to save the current view of the tree. The point is to generate the migration history that can be replayed safely on other targets later.
What the migration files actually mean
Migration files are the ordered record of how the database schema should change over time. They are not the same thing as editing live rows, and they are not just backup files. Each migration describes a structural change such as creating a table, adding a column, or changing a relation, so another target can apply the same schema update in the same order.
Test the changes on development targets first
After the migration files exist, keep working against the development target until the app behavior proves the schema is correct. Update or test the affected queries, forms, server actions, validators, and seeded data there first. This is where you catch naming mistakes, missing fields, and relation assumptions before the same migration reaches a real deployment.
Choose a database strategy that fits the project
Not every project needs the same target layout. A small one-person project can sometimes keep one shared database if the risk is low and the workflow is simple. A larger team, a staging workflow, or any project where testing and release timing matter should usually keep separate databases per target or environment so development changes cannot surprise the live system.
Publish applies the approved schema to the live target
When the project is ready, the publish flow is where the approved migration history moves to the live environment. That means the live target receives the same structural updates you already proved on development, instead of you manually rebuilding the schema by hand. This is the safer deployment story: design in Database Manager, test in development, then publish with migrations so the live database is updated as part of the release workflow.
Next steps
Return to the main Database Manager hub when you are ready for the next subject. That keeps the database learning path sequential, with the main hub acting as the place to choose the next lifecycle, recipe, or reference topic.