Functorial Data Migration

Spivak’s functorial data migration reads a database schema as a category, a database instance as a set-valued functor, and the movement of data between schemas as functors between such functor categories. The design idea is that “dataset design” becomes schema design plus a schema mapping, and the migration is forced by the mapping rather than hand-written.

Schemas, instances, mappings

A schema is a small category . Objects are tables, morphisms are foreign-key columns, and path equations impose the business rules. An instance is a functor sending each table to its set of rows and each column to the lookup map; instances and natural transformations form the category . A schema mapping is itself a functor .

The three migration functors

A mapping induces a pullback functor and its two adjoints, moving instances between the two schemas:

is restriction along . Its left adjoint is the left Kan extension, which glues rows and acts roughly as a projection or union, whereas its right adjoint is the right Kan extension, which takes matching families and acts roughly as a join.

Property. Migration is Kan extension along a functor

The migration is determined once is fixed, since and are the Kan extensions of an instance along the mapping . Adjunctions thereby replace the query language. What a user would write as select/join/union is the image of a single schema mapping under .

Layering and the institution reading

In practice the schemas are stratified: a README describing intent, a Meta schema (itself a schema-of-schemas, and largely auto-generated), a Master layer for reference data, and a Transaction layer for events, with mappings between the layers. The functorial-model semantics lines up with the notion of an institution, comprising signatures, models, sentences, and a satisfaction relation stable under change of signature. Thus “schema + instances + constraints, moved coherently” is one instance of the general model-theoretic pattern.