DevOps: Database Change Management with PostgreSQL
This is a series of articles about DevOps: Database Change Management with PostgreSQL.
- DevOps: Database Change Management with PostgreSQL (this one)
- DevOps: Database Change Management with PostgreSQL and GitHub
PostgreSQL is the world's most advanced open-source relational database management system.
This tutorial is a step-by-step guide to setting up Database Change Management for PostgreSQL in Bytebase. With Bytebase, a team can have a formalized review and rollout process to make PostgreSQL database schema change and data change.
Bytebase provides a GUI for teams to perform Database Changes and retain full Change History. Bytebase Free Plan is sufficient for this tutorial.
In the end, there is a bonus section about Schema Drift Detection for those advanced users.
- Change Workflow
- Schema Editor
- SQL Advisor
- Change History
- SQL Editor Admin Mode
- Drift Detection
Before you start, make sure you have Docker installed.
Step 1 - Deploy Bytebase via Docker
- Make sure your Docker daemon is running, and start the Bytebase Docker container with following command:
Bytebase is now running via Docker, and you can access it via
localhost:5678in your browser. Register the first admin account which will be granted
Step 2 - Add PostgreSQL in Bytebase
In Bytebase, an Instance could be your on-premises PostgreSQL instance, an AWS RDS instance etc, in this tutorial.
localhost:5678and log in.
Click Instances on the top bar you’ll see there is a sample PostgreSQL instance that is embedded. If you want to use your own instance, click Add instance. To keep it simple, we’ll use the built-in sample instance for this tutorial.
Step 3 - Create a Project
In Bytebase, Project is the container to group logically related Databases, Issues and Users together, which is similar to the project concept in other dev tools such as Jira, GitLab. So before you deal with the database, a project must be created.
Click Projects on the top bar, and you’ll see there is already a sample project. We’ll use it for this tutorial. You can also click New Project to create a new one.
Step 4 - Create a database in PostgreSQL via Bytebase
In Bytebase, a Database is the one created by "CREATE DATABASE xxx". A database always belongs to a single Project. Issue represents a specific collaboration activity between Developer and DBA such as creating a database, altering a schema. It's similar to the issue concept in other issue management tools.
Go back to Home, and click New DB.
Fill the form with
Postgres Sample instance
- Database owner name:
bbsampleAnd click Create.
- It will create an issue "CREATE DATABASE …" automatically. Because it’s for
Prodenvironment, the issue won’t run till you click Approve. Click Resolve, and the issue is
Done. The database is created.
- Go back to the home page by clicking Home on the left sidebar. On the home page, you can see the newly created database
demo, and the issue you just resolved.
Step 5 - Create a table in PostgreSQL via Bytebase
In Step 4, you actually created an issue in UI workflow and then executed it. Let’s make it more explicit.
Go to project
Sample Project, and click Alter Schema.
demoand click Next. It could generate a pipeline if you have different databases for different environments.
There are two options Schema Editor and Raw SQL, here we choose Schema Editor to create a table
t1via UI. Click Add Column to add a
namecolumn. Click Preview issue.
Title and SQL will be filled automatically. You can select the Assignee to review the issue and then click Create.
Bytebase will run some basic checks and wait for the Assignee to approve.
Click Approve and the SQL will execute. Click Resolve issue and the issue status will become
On the issue page, click View change. You will see the database difference.
You can also go to Change History under the project to view the full history. Or go into a specific database to view its history.
Bonus Section - Schema Drift Detection
This section requires you to have Enterprise Plan (you can start 14 days trial directly in the product without credit card).
Now you can see the full change history of
demo. However, what is Establish new baseline? When should it be used?
By adopting Bytebase, we expect teams to use Bytebase exclusively for all schema changes. Meanwhile, if someone has made PostgreSQL schema change outside of Bytebase, obviously Bytebase won’t know it. And because Bytebase has recorded its own copy of schema, when Bytebase compares that with the live schema having that out-of-band schema change, it will notice a discrepancy and surface a schema drift anomaly. If that change is intended, then you should use baseline the schema state again to reconcile.
In this section, you’ll be guided through this process.
- You can use an external GUI or terminal to make a change to
demo. In this tutorial, we use Bytebase SQL Editor’s Admin mode which also counts when we say change outside of Bytebase. Go to SQL Editor, and switch to Admin mode.
When you make a change in Admin mode, it will not record any history as in a normal process www.bytebase.com/docs/sql-editor/admin-mode
- Paste the following and then press Enter:
- Paste the following and then press Enter to verify it’s there:
Admin mode skips Bytebase system and works as an external input. The change will take effect in Bytebase GUI in the next sync.
Wait for 10 mins. Go to Anomaly Center, and you can find the Schema Drift.
Click View diff, and you’ll see the drift.
You may also find the drift by clicking Databases > demo.
Go to Databases > demo > Change History and click Establish new baseline.
It will create an issue. Click Approve and Resolve to make it
Go back to Databases > demo or Anomaly Center, and you will find the drift is gone.
Summary and Next
Now you have connected PostgreSQL with Bytebase, and tried out the UI workflow to do schema change. Bytebase will record the full change history for you. With Enterprise Plan, you can even have schema drift detection.
In the next article, you’ll try out GitOps workflow, which will store your PostgreSQL schema in GitHub and trigger the change upon committing the change to the repository, to bring your PostgreSQL change workflow to the next level of Database DevOps - Database as Code.