Kleisli Database Instances

We use monads to relax the atomicity requirement for data in a database. Depending on the choice of monad, the database fields may contain generalized values such as lists or sets of values, or they may contain exceptions such as various types of nulls. The return operation for monads ensures that any ordinary database instance will count as one of these generalized instances, and the bind operation ensures that generalized values behave well under joins of foreign key sequences. Different monads allow for vastly different types of information to be stored in the database. For example, we show that classical concepts like Markov chains, graphs, and finite state automata are each perfectly captured by a different monad on the same schema.

💡 Research Summary

The paper “Kleisli Database Instances” proposes a categorical framework that lifts the traditional atomicity constraint of relational databases by embedding monads into the schema‑instance relationship. In the classic setting a database schema is a small category C and a database instance is a functor F : C → Set, assigning to each object (table) a set of rows and to each arrow (foreign key) a function between those sets. The authors observe that this formulation forces every attribute to hold a single, indivisible value.

To relax this, they introduce a monad T : Set → Set (for example List, Multiset, Maybe, Either, or a probability distribution monad) and replace the ordinary Set‑valued functor with a T‑valued functor FT : C → Set. Concretely, each attribute now stores a T‑value – a list, a bag, an optional value, an error tag, or a probability distribution – rather than a plain element. The monad’s unit (η, often called return) embeds ordinary values into T‑values, guaranteeing that any classical instance is also a T‑instance. The bind operation (≫=) becomes the mechanism that propagates and combines T‑values along foreign‑key paths, i.e., it defines how joins behave when the participating columns contain generalized values.

From a categorical perspective the authors work in the Kleisli category Kleisli(T). Objects are still sets, but morphisms X → Y are functions X → T Y. Composition in Kleisli(T) is precisely bind, and the unit is η. Thus a database instance can be seen as a functor C → Kleisli(T). This viewpoint preserves all the familiar categorical properties of database mappings (limits, colimits, pullbacks, etc.) while enriching the value domain.

The paper explores several concrete monads and demonstrates how they give rise to distinct information‑storage capabilities:

• List monad – enables ordered collections in a column, useful for representing sequences, paths, or logs. The bind operation concatenates the results of applying a function to each list element, which models the usual “flatten‑and‑join” behaviour.

• Multiset (Bag) monad – allows duplicate elements, ideal for modeling graphs with multiple edges, counting aggregates, or any scenario where multiplicity matters. The monadic multiplication merges bags by summing multiplicities.

• Maybe/Option monad – captures nullable fields or the presence/absence of a value in a principled way, turning the ad‑hoc NULL semantics of SQL into a mathematically clean construction.

• Either monad – distinguishes normal results from error codes, providing a structured way to store and propagate exceptions within the database.

• Distribution monad – represents probability distributions over a set, which the authors use to encode Markov chains directly in the schema. Transition probabilities are stored as distribution values, and successive steps are computed by repeatedly binding the distribution monad.

To illustrate the expressive power of this approach, the authors encode three classic computational structures on the same underlying schema:

1. Markov chains – states are rows, and the transition matrix is stored as a distribution monad value in a “next” column. The unit injects the initial state, and the bind operation composes transitions, yielding the distribution after any number of steps.

2. Directed graphs – vertices are rows, and adjacency lists are stored as multisets of target vertex identifiers. Path queries are expressed by iterating bind over the adjacency multiset, effectively performing a breadth‑first or depth‑first traversal within the categorical framework.

3. Finite‑state automata – states and input symbols are represented with Option monads; undefined transitions become “None”. The automaton’s transition function is a Kleisli arrow, and processing an input word corresponds to a chain of binds that either yields a final state or propagates a failure.

These examples demonstrate that by merely swapping the monad, the same schema can host vastly different kinds of data and semantics without altering the underlying query language or schema definition.

On the implementation side, the authors discuss two realistic pathways. First, a conventional relational engine could be extended with a “monadic layer” that interprets T‑valued columns and rewrites bind‑based joins into native SQL constructs such as UNNEST, ARRAY_AGG, or user‑defined table‑valued functions. Second, a new DBMS built on a functional language (e.g., Haskell or OCaml) could natively represent Kleisli arrows, allowing the bind operation to be compiled directly into efficient data‑flow pipelines. The paper also mentions monad transformers as a way to combine several monads (e.g., List ∘ Maybe) to model even richer data structures.

In conclusion, “Kleisli Database Instances” provides a mathematically elegant and practically versatile method for generalizing database values. By leveraging monads and the Kleisli category, it retains the categorical foundations of database theory while opening the door to non‑atomic, probabilistic, and exception‑aware data models. This work bridges the gap between functional programming semantics and relational data management, suggesting a promising direction for future database language design and system implementation.