Apply a database change to every customer database

Database changes applied to a few databases at a time, with a result for each one

When each customer has its own database, a change to the database structure has to reach many separate databases. The migration runner applies a service’s changes to a limited number of databases at a time and records progress for each one. A failure in one database is kept apart, so operators can inspect it and retry it separately.

Built in

What you get

Apply a service’s database changes to every customer database
A result and a retry for each database keep one failed change apart from the rest of the run
A limit on how many databases are changed at once keeps the run fast and controlled
Live progress in the operator console
Connection details are removed from every log line
The same runner for one customer or thousands

Under the hood

How it works

Run one database change across customer databases

The operator chooses a service and a version of its database structure. The runner lists that service’s customer databases, applies the pending changes to a limited number at a time, records each result and leaves failed databases available to inspect and retry.

One failed database does not stop the run

If one customer’s database is in the middle of an incident, or differs from what is expected, its change fails alone and the run continues. You get a clear list of the databases that succeeded and those that need attention. The run does not stop for every customer at the first error.

Pairs well with

Related capabilities

Multi-tenancy

Checks on every request, a separate database, or dedicated infrastructure

Organizations, Plans & Settings

One record of every customer, app, plan and setting, with overrides for each customer

Want a deeper walkthrough of Customer Database Updates?

A solution architect will demo the live service against your domain model.

Get a deployment assessment