GENERAL OPINIONS

• "You should never tie database migrations to application deploys or vice versa. By minimising dependencies you enable faster, easier and cleaner deployments."
• "Backward compatibility with older versions of a database schema is typically something to avoid, and hacking your Data Access Layer to support multiple schema versions feels like a design smell."
• "Forward compatibility is tricky because you have old code running that now need to handle a new use-case it was not designed to handle when it was initially written."

1. Migrate data to catalog

Persists data in catalog structure.

Problems

• Time
• Money
• ALL code has to be backward AND forward compatible.
• Not all metadata is in catalog structure

2. table versioning

Create a copy from original table with the new changes.

PROBLEMS

• Legacy Code
• Complexity on our code
• Database chaos
• Time

3. single data access service

All data should be persisted and loaded using a single service. This service should handle database schema changes and deliver data according the version of the client.

• Backward compatibility: use default value in case the clients have not been deployed yet and do not send the new field.
• Forward compatibility: Old service versions have to ignore unknown fields and parameters, the services are resilient to API extension.

PROBLEMS

• Change current architecture
• Time and cost
• Performance

TIPS

• Every change you make must be backward compatible with the rest of the system.
• A cleaner solution is to ensure that your code is always running against the version of the schema which that code has been written for.
• Store every change in the database schema
• SQL script files for downgrade and upgrade
• Every SQL script file must be immutable after it is deployed to production or staging environment.
• All changes in the database’s schema and reference data have to be applied through the scripts. Neither of them can be applied manually.
• Autotesting