Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Database migrations without downtime #1236

glerchundi opened this issue Dec 13, 2018 · 3 comments


Copy link

@glerchundi glerchundi commented Dec 13, 2018

Is your feature request related to a problem? Please describe.

We would like make ORY Hydra upgrades without incurring in service downtimes.

Describe the solution you'd like

An expand-and-contract pattern to be implemented

Describe alternatives you've considered

Deal with downtimes.


This comment has been minimized.

Copy link

@aeneasr aeneasr commented Dec 13, 2018

Without more context and without technical details how to implement this, and given the very real and complex nature of SQL migrations, this is not something that can be considered by this project. Feel free to provide more details and concrete proposals despite closure of this as a nofix.

@aeneasr aeneasr closed this Dec 13, 2018

This comment has been minimized.

Copy link
Contributor Author

@glerchundi glerchundi commented Dec 13, 2018

The expand and contract pattern is a way to handle with breaking changes to persistent data without downtime. Take a look to this document.

But basically it would require ORY Hydra to follow these steps:

  1. Introduce new structure

    1. Create the new structure.
    2. Change any writing code to write to both places (old and the new structures). Under normal circumstances such duplication is bad, but it's only a temporary measure. Everything will be properly normalised when finished.
  2. Migrate Data
    Once that code is successfully live everywhere, you can then run a migration on all the existing data.

  3. Operate on new structure
    Once you're sure that both tables are perfectly in sync, and are staying that way, you can start to migrate all code that reads to use the new table.

  4. Stop writing on old structure
    When you're sure that no code reads from the old table you can remove the old code that writes to it, leaving, of course, the code that writes to the new table.

  5. Delete old structure
    Once that's live everywhere, you can delete the old structure.

Do you think this is something that you wouldn't consider?


This comment has been minimized.

Copy link

@aeneasr aeneasr commented Dec 14, 2018

That's an interesting concept! However, it looks like it would be very challenging to set up a proper test plan and make sure that everything runs smoothly with every release. I fear that we don't have the resources / incentives to support and maintain this. Sorry!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.