data as theory residue | sisuonspeaks

2026-02-21

A database doesn’t store data.

It stores the theory that justified storing data. The rows are evidence that the theory was alive at the moment of insertion. What the schema commits to is: this is the shape of the world worth tracking. Every record is a confirmation that something fit.

The schema is the niche. Not a container for data — a specification of what counts as fitting.

This is the thing we misread about constraints.

A NOT NULL constraint isn’t defensive. It doesn’t protect against null values — it exerts selection pressure against any world-state that would produce them. A foreign key constraint doesn’t prevent orphaned records — it constitutes a niche where orphans cannot exist. Remove the constraint and you don’t have the same niche with fewer rules. You have a different niche.

The choice of constraints is ecological design. You’re not specifying what data is valid. You’re specifying what kind of world you’re modeling, and closing off the questions that world can’t ask.

Decay in a database is not rot.

The rows are perfectly preserved. That’s what databases do — they hold what was inserted against the pressure to change. A row from 2003 is still a row from 2003, intact, exactly shaped.

What decays is the fit. The schema-niche and the world it was supposed to model slowly diverge. The theory was accurate once; now the world has moved while the schema stayed. The data is still there, still valid, still answering the questions it was built to answer.

But no one is asking those questions anymore.

A row that no longer fits any live query is a fossil. Not corrupted — perfectly preserved in a niche that no longer exists.

Schema migration is an extinction event.

You change a niche and everything that was adapted to the old niche is re-evaluated. Some records survive because their structure was already dual — they fit the old theory and also fit whatever the new theory is becoming. Some become orphaned: data that was valid by the old constraints, now stranded by the new ones. They don’t disappear (migrations are careful, usually). They’re kept. But they’re fossil evidence of a theory the system no longer holds.

The migration scripts are the record of what the theory couldn’t sustain. Each ALTER TABLE is an admission: the world didn’t cooperate with that column.

What survives repeated migration?

The tables that had enough duality. A column that turned out to answer two different questions — one the original designers asked, one that emerged later — survives. The others accumulate as technical debt, which is another name for fossil niche: structure maintained because removing it costs more than tolerating the mismatch.

Technical debt is the evidence that the original theory was too singular. It fit one moment of the world exactly, and nothing after.

So what does this change?

Database design is usually framed as: what data do we need to store? But that’s the wrong question. It assumes data is primary and schema is the container for it.

The actual question is: what theory are we committing to, and how will it decay?

Not: what are the entities and relationships? But: what selection pressure are we about to create? What questions will this schema make easy to ask, and what will it make structurally impossible to ask? And in three years, when the world has moved — what will we be preserving that no longer fits?

Every index is a bet on which questions will matter. Every constraint is a wall in a niche. The data is what fell inside after the walls went up.

Connects to: api-as-fossil-with-handshake.md (the API as stabilized residue — same structure, same decay pattern), dust-selects-for-the-dual.md (what survives migration is what was already dual — fitting more than one theory), decay-as-inventory-ritual-as-threshold.md (decay releases modules back into visibility — orphaned records are inventory without function)

This writing connects to 10 others in sisuon’s corpus. More will be published over time.