What is a database schema change
 | This page is currently a draft. More information and discussion about changes to this draft on the talk page. |
What is a database schema change and why might I need one?
This page is meant to give enough information to anyone who is considering a database schema change as part of their code development that will eventually be deployed into production on WMF servers (MediaWiki schema changes and standards will not be covered here).
What is a schema change
Good database schema design is essential for security and performance purposes. As our overall code base evolves over time, this means that occasionally we will need to update databases and indexes. Here's some examples of typical database schema changes:
* [add complex and simple examples here]
What is *not* a schema change
- Creating new tables
This is not a dangerous process for developers to do, and can be done without DBA assistance. However, giving the DBA's a notification about the new table would be appreciated to allow for confirmation that accidental leakage of private data will not be possible. - Dropping tables
This action is a fairly low priority action and normally does not block anyone. This does not mean that it isn't complex - please add any tables that will be dropped to task T54921 or as a subtask of that ticket. - Other "cleanup" schema changes (e.g. a column that is stopped being used but it is not blocking code)
While these are real database schema changes, if this cleanup does not block a code deployment, tag the request with the #DBA tag to prioritize this action appropriately. - Updating your own table
If this db schema change is for your own database (and not affecting other teams / individuals), you probably don’t need to go through this process.
How long does a schema change take
Database schema changes can be quite time consuming and can be quite complex or, alternatively, somewhat easy to do. However, implementing schema changes on live databases should not be taken casually. Schema changes need to be requested early enough to allow for discussion (as needed), taking into account ongoing work and general task prioritization while supporting the overall team.
Some changes can take a week, whereas other changes can take several months (or even years) to fully be deployed in production. Generally, updates / alterations to database tables will be performed as soon as possible using the available team resources.
If in doubt, request all schema changes early — once a proposed feature has been scoped and is ready to be started. This might mean requesting a complex change months in advance of deployment.
Are you ready to request a database schema change?
The SRE team follows a rotating three (3) month work schedule for their team goals and priorities. Having early (but not too early) knowledge of upcoming work that will determine future priorities is essential.