The Ownership Problem in Database Schemas
In most organisations, schema ownership is implicit. The person who created a table moves on, and years later no one knows who decided that a column should be NOT NULL or why a foreign key points to a specific table.
Explicit ownership means that every table, column, and relationship has a named individual or team responsible for its definition. When someone proposes a change, the owner is consulted. When a field's meaning becomes ambiguous, the owner is the first person to ask.
Ownership Roles
Define these roles for every entity in your schema.
Data Owner
The individual accountable for the business meaning of the data. The data owner approves changes to the definition, validates that the schema still serves its business purpose, and is the escalation point for ambiguity.
Technical Custodian
The team responsible for maintaining the table's physical structure: indexes, constraints, migrations, and performance. The custodian implements changes approved by the data owner.
Data Consumer
Any team or system that reads from the table. Consumers should be notified before structural changes are deployed, as modifications can break downstream queries and pipelines.
Review Board
A cross-functional group that reviews schema changes affecting multiple teams. The board ensures that proposed modifications align with architectural standards and do not introduce hidden dependencies.
Ownership Documentation Template
For every table, record the following ownership information in your schema documentation:
- Table: [table_name]
- Data Owner: [name or team]
- Technical Custodian: [team name]
- Known Consumers: [list of teams/systems]
- Review Required: [Yes/No — for changes affecting consumers]
- Last Reviewed: [date]
Review ownership assignments at least once per quarter. When team members change roles, update the documentation immediately to prevent ownership gaps.
Ready to assign ownership?
Continue your schema-intent review with related materials.