# Managing db schema changes without downtime

DevFeed: [Managing db schema changes without downtime](<https://devfeed.tech/articles/managing-db-schema-changes-without-downtime-41346.md>)

Original publisher: [Read original article](<https://samsaffron.com/archive/2018/03/22/managing-db-schema-changes-without-downtime>)

Author: Sam Saffron

Published: 2018-03-22T06:30:05Z

Content type: article

Language: en

Sources: [Sam Saffron](<https://devfeed.tech/sources/sam-saffron.md>)

Topics: [Database Migration](<https://devfeed.tech/topics/database-migration.md>), [migration](<https://devfeed.tech/topics/migration.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>), [Rails](<https://devfeed.tech/topics/rails.md>), [CI/CD](<https://devfeed.tech/topics/cicd.md>)

Tags: [activerecord](<https://devfeed.tech/tags/activerecord.md>), [commit](<https://devfeed.tech/tags/commit.md>), [continuous-deployment](<https://devfeed.tech/tags/continuous-deployment.md>), [database](<https://devfeed.tech/tags/database.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [downtime](<https://devfeed.tech/tags/downtime.md>), [exceptions](<https://devfeed.tech/tags/exceptions.md>), [integration-test](<https://devfeed.tech/tags/integration-test.md>), [outage](<https://devfeed.tech/tags/outage.md>), [schema](<https://devfeed.tech/tags/schema.md>)

## AI overview

This article explains how database schema changes can cause deployment outages, especially when older application instances remain active and ActiveRecord caches schema information. It describes Discourse's use of richer migration logging and deployment patterns to reduce these risks.

## Source excerpt

At Discourse we have always been huge fans of continuous deployment. Every commit we make heads to our continuous integration test suite. If all the tests pass (ui, unit, integration, smoke) we automatically deploy the latest version of our code to https://meta.discourse.org. This pattern and practice we follow allows the thousands of self-installers out there to safely upgrade to the tests-passed version whenever they feel like it. Because we deploy so often we need to take extra care not to have any outages during deployments. One of the most common reasons for outages during application deployment is database schema changes. The problem with schema changes Our current deployment mechanism roughly goes as follows: Migrate database to new schema Bundle up application into a single docker image Push to registry Spin down old instance, pull new instance, spin up new instance (and repeat) If we ever create an incompatible database schema we risk breaking all the old application instances running older versions of our code. In practice, this can lead to tens of minutes of outage! In ActiveRecord the situation is particularly dire cause in production the database schema is cached and any changes in schema that drop or rename columns very quickly risk breaking every query to the affected model raising invalid schema exceptions. Over the years we have introduced various patterns to overcome this problem and enable us to deploy schema changes safely, minimizing outages. Tracking rich information about migrations ActiveRecord has a table called schema_migrations where it stores information about migrations that ran. Unfortunately the amount of data stored in this table is extremely limited, in fact it boils down to: connection.create_table(table_name, id: false) do |t| t.string :version, version_options end The table has a lonely column storing the "version" of migrations that ran. It does not store when the migration ran It does not store how long it took the migration to