In a large enterprise, multiple teams write directly to the same core business tables and change schemas independently. What problems emerge, and what governance changes fix them without stopping delivery?

The problems that emerge

No owner means no invariant. When several teams write to the same table, no one can state what is always true of it. Business rules are enforced by whichever code path happened to be used, so the same logical operation validates differently depending on its origin — and the data eventually violates constraints everyone assumed were held.

Schema changes become outages. A team adds a NOT NULL column with a default; another team's batch insert, which does not know about it, fails at 2 a.m. A column is renamed; three integrations break, two of which are owned by teams the changer cannot name.

Migrations lock. A long-running ALTER on a large hot table blocks writers, so a routine change becomes an incident, and the fear of that makes teams avoid necessary migrations — accumulating debt because change feels dangerous.

Deployment coordination becomes the bottleneck. Because the schema is shared, releases must be sequenced, so team velocity drops to the slowest participant. This is usually the cost that finally gets attention, since it is visible on a roadmap in a way that data quality is not.

Nobody can refactor. The table's structure is a de facto public API that no one published, with unknown consumers. It ossifies.

The governance changes that work

1. Assign single ownership per table, without moving all the code. One team is accountable for the schema, the invariants and the migration path. Others may still read, but writes go through the owner's interface — a service, a stored procedure, or a package with enforced boundaries. Ownership is the prerequisite for every other fix.

2. Treat schema changes as contract changes with expand-and-contract. Add the new column nullable; deploy code writing both; backfill; deploy code reading new; then remove old. Every step is independently deployable and reversible, so no release requires sequencing across teams. This is the single most valuable technique here, because it converts coordination into a protocol.

3. Publish a read contract. Consumers read a view or a replicated dataset, not base tables. The owner can refactor underneath as long as the view holds, which restores the ability to change internal structure.

4. Enforce in the pipeline, not the review. Migration linting in CI — no blocking DDL on large tables, no destructive change without a deprecation period, no new column without an owner tag. Reviews catch what people remember; pipelines catch what they do not.

5. Make consumers discoverable. A registry of who reads what, ideally derived from query logs rather than self-declaration. Most of the fear around schema change is fear of unknown consumers, and that is an information problem with a technical solution.

What not to do

Do not create a central approval board for schema changes. It becomes a queue, teams route around it with "temporary" tables that become permanent, and the data landscape fragments further. Governance that slows delivery is defeated by the organisation, reliably and quickly.

Do not immediately split the database per team. Sometimes correct, often premature — it converts consistency problems into distributed-transaction problems and can make things considerably worse before ownership and contracts are established.

The principle

Shared mutable state without an owner is the same defect at data scale as it is in code. The fix is identical: establish ownership, define an interface, make changes backwards-compatible by protocol, and enforce it with tooling rather than with meetings.