Database XP

About Database XP

Applications are replaced every few years. The data survives every replacement, carrying whatever decisions were made when nobody was paying much attention.

There is a reliable pattern in long-lived systems. The application gets rewritten: a new framework, a new language, a new team, a new front end. This happens perhaps every five to eight years, and each time it is treated as a substantial undertaking. The database is migrated across, largely unchanged, because changing it is harder than changing the code and because everything else depends on it. After two rewrites the schema is the oldest surviving artefact in the system, and it is carrying decisions made by somebody who left a decade ago.

This asymmetry should change how much care goes into each. A poor choice in application code is annoying and can be fixed by somebody willing to do the work, because the code has no state. A poor choice in a schema propagates: every application written against it inherits it, every report depends on it, every integration encodes it, and by the time somebody wants to change it there are eleven consumers nobody has a complete list of.

An operation that is instant on a thousand rows locks a hundred million.

Database XP is about the parts of data work that outlive the applications built on them: schema decisions, constraints, migrations at scale, backups that have actually been restored, indexing trade-offs, and documenting meaning rather than structure.

The editorial position is that schemas outlast the code written against them by several rewrites, that the decisions which are expensive to reverse deserve disproportionate care, and that data integrity enforced only in an application will be bypassed by the second thing that writes to the database.

Explore topics & services

Useful website links