Development Environments

Schema and code changes must be deployed in the correct sequence. When adding a new column to a table along with a new application feature, you likely want to execute the schema change before deploying the corresponding code changes. In other cases, such as removing a feature and with it a table in your database, you would make your code changes first and then drop the table second.We recommend reviewing this blog post for more information about deploying database schema changes alongside application changes.

Use local Postgres

Since PlanetScale uses standard PostgreSQL, one option is to use locally-running Postgres servers for all of your development work.

In this case, you would create a new local database for each branch a developer is working on. After creating the database, run your database migration scripts to populate it with your project’s schema. Optionally, you could have a script to populate your tables with dummy data to improve local testing. When you are ready to commit your code changes, execute the necessary schema changes on your production branch, being careful about ordering.

While this is a convenient option in some cases, local databases can make it difficult for multiple developers to collaborate on shared branches, as schema changes must be manually synchronized across each developer’s local environment.

Use PlanetScale branches

PlanetScale Postgres supports branching. This allows you to spin up lightweight Postgres databases separate from production that can be used for development and testing. Creating a new branch produces a completely empty Postgres database. No schema or data is copied to the branch, unless restoring from a backup (more on this later).

Branches can be used similarly to local Postgres instances. The advantage is, since they are hosted by PlanetScale, they can be easily shared amongst development teams.

If using branches for your development environments, you would create new database branch for each code branch a developer/team is working on. You would then run your schema migrations and any data loading scripts you need to initialize the branch. When you are ready to commit your code changes, execute the necessary schema changes on your production branch, and then delete the branch.

Use PlanetScale branches + backups

PlanetScale gives you the ability to create new branches that are initialized from a recent backup. This can be used instead of empty branches to create development environments that are pre-populated with schema and data.

There are some downsides to this approach, however. This approach copies production data to development branches, which may pose security risks if your database contains sensitive customer information.

Another consideration is cost. Each branch is its own, isolated database and uses its own storage separate from production. You will be charged for the storage consumed by both your production branches and your development branches.

​Use local Postgres

​Use PlanetScale branches

​Use PlanetScale branches + backups

​Need help?

Use local Postgres

Use PlanetScale branches

Use PlanetScale branches + backups

Need help?