Plan

Define database work and follow its checks, review, and deployment in one place.

A Plan is the main record of database work in a project, from preparation through deployment. It defines the work and its targets and links the review and execution records. For schema or data changes, it stores SQL or a reference to a Release. The Plan keeps its identity throughout the change.

For example, a Plan can add a column to an application’s Test and Prod databases and track deployment to each. Changes to existing databases target those databases; a Plan that creates a database targets its instance.

Plan, Issue, Release, and Rollout

These resources describe different parts of the same change:

Resource	Responsibility
Plan	Defines the work and targets, and tracks the whole change.
Issue	Records a request’s review, discussion, and approval.
Release	Supplies a saved, immutable package of SQL files.
Rollout	Groups execution tasks into stages and records their results.

A UI Plan usually stores SQL entered in Bytebase and has a linked Issue for review. The GitOps workflow creates a Plan from a Release after pull-request review and CI checks, without a Bytebase Issue review step. Both workflows use Rollouts to track execution.

Create a Plan

For a schema or data change, open your project’s CI/CD → Plans → New Plan. With change-creation permission, select the target databases, enter SQL or use Schema editor, and give the Plan a descriptive title. Click Create to save the Plan, start automated checks, and create its linked draft Issue.

In this example, a saved Plan proposes adding employee.nickname in hr_test. The checks have finished, but the SQL has not run.

For GitOps, the deployment job creates a Plan referencing a Release and the selected targets. Follow the GitOps tutorial for that workflow. Database creation uses Create Database; see Database.

Follow review and deployment

Open the Plan from CI/CD → Plans. Changes shows the proposed work and, for UI changes, automated checks. Review, when present, shows the linked Issue’s approval flow and discussion. Deploy shows the Rollout and its task results.

For a UI change to existing databases:

1. Inspect the SQL, targets, and check findings. After an edit, read the updated results.
2. Click Ready for Review to submit the draft Issue. Approval rules determine whether a reviewer decision is required.
3. Once approval is satisfied and checks finish without errors, Bytebase automatically creates the Rollout.
4. Follow execution in Deploy. Manual environments wait for Run; automatic environments execute according to rollout policy.

The Plan shows Deployed when the Rollout completes. Inspect the task results to confirm what executed; a skipped task can also count toward completion. See Rollout for task states and retries.

For authoring, submission blockers, and deployment steps, see Plan authoring or the UI tutorial.