Database Schema Change Policy


This document lays out the policy for adding, deleting or altering any database object, user or configuration. This policy is a necessity to efficiently manage the database schema as we grow.

Authorized People

All schema changes will be performed by the Database Team, unless someone is authorized by a senior member of the Database Team[1].

Schema Change Requests

The policy for schema change requests is different based on whether the database is a development database or a production database.

Development Database

1.       The developer will have a meeting with the Database Team and discuss his/her requirements and the application specifications. The developer should not only talk about the current needs of the application but also inform the Database Team of future implications, expectations and requirements. Once the schema design is agreed on, the Database Team will send email detailing the proposed schema changes to the developer.

2.       The developer will be required to provide documentation[2] for the schema changes. (Schema changes will not be made unless adequate documentation is supplied)

3.       Upon receipt of the documentation from the developer the Database Team will provide the developer with an ETA via email.

4.       Once the schema changes have been made the Database Team will send email to the developer informing him/her that the requested changes have been made.

5.       The developer will then be required to check and verify the changes and inform the Database Team via email whether the changes are good and don’t need a review, until and unless the Database Team receives such an email, schema changes will be considered temporary and will not be propagated to the production database.

Production Database

1.       Unless there is an extreme emergency schema changes will not be made to the production database unless they have been tested on the development database.

2.       When a developer wants a certain set of schema changes to be propagated to the production database he/she will be required to send email to the Database Team requesting the change. The email should refer to the changes made on the development database.

3.       The Database Team will respond with an email to the developer listing the permanent[3] changes that their records show.

4.       The developer will then respond with an email confirming that the listed changes are indeed the ones he/she requires (this email should be sent at least one business day before the change is required)

5.       The Database Team will then email the developer providing him/her with an ETA, including the Database Change window that this schema change is scheduled to take place in

6.       The Database Team will make the change in the scheduled DBC window[4]

7.       The Database Team will send out an email to the developer upon completion of the schema changes in production


The Managers of System Development are responsible for enforcing this policy within their team, and making sure that all the team members are aware of it. It is imperative that we adhere to this policy to ensure the proper management of the databases.

[1] A Senior member of the database team is either System Architect or a Senior DBA

[2] The documentation should have a brief description of each table involved, and a short description for each column in the tables

[3] A change is not considered permanent until and unless the requesting developer confirms the changes on the development database as per Section “Schema Change Requests” sub-section “Development Database”

[4] As per the Production Database Change Policy