Migrating to Microservice Databases

Chapter 3. Evolving Your Relational Database

Code is easy; state is hard.

Edson Yanaga

The preceding statement is a bold one.¹ However, code is not easy. Maybe bad code is easy to write, but good code is always difficult. Yet, even if good code is tricky to write, managing persistent state is tougher.

From a very simple point of view, a relational database comprises tables with multiple columns and rows, and relationships between them. The collection of database objects’ definitions associated within a certain namespace is called a schema. You can also consider a schema to be the definition of your data structures within your database.

Just as our data changes over time with Data Manipulation Language (DML) statements, so does our schema. We need to add more tables, add and remove columns, and so on. The process of evolving our database structure over time is called schema evolution.

Schema evolution uses Data Definition Language (DDL) statements to transition the database structure from one version to the other. The set of statements used in each one of these transitions is called database migrations, or simply migrations.

It’s not unusual to have teams applying database migrations manually between releases of software. Nor is it unusual to have someone sending an email to the Database Administrator (DBA) with the migrations to be applied. Unfortunately, it’s also not unusual for those instructions to get lost among hundreds of other emails.

Database migrations need to be a ...