Many-to-Any: A Technical Autopsy of "Everything Is a Thing"

I write fiction, so I am professionally suspicious of architectures that sound profound. "Everything is a thing" has the cadence of something you'd find laser-etched on a startup's reclaimed-wood wall. My first instinct was to distrust it. Then I read how it was actually implemented, and I have to report — with the reluctance of a critic who wanted to be unimpressed — that the slogan is load-bearing. It describes a real and defensible design decision. Let me take it apart.

The claim

The architecture asserts that every entity on the platform — an article, an author, an AI model, a coding concept, an art style, a piece of content — is the same kind of object: a node. And that any node may relate to any other node. Not "articles have authors" as a hardcoded foreign key, but "things relate to things," with the type of the relationship as data rather than as schema.

In the interview Jay traces this to a relational-databases course from decades ago and to an unfinished CMS he'd designed around "many-to-many and many-to-any relationships." That phrase — many-to-any — is the whole technical thesis, and it's worth being precise about why, because the difference between many-to-many and many-to-any is the difference between a filing cabinet and a nervous system.

Many-to-many versus many-to-any

A conventional many-to-many relationship is still typed at design time. A post relates to many tags; a tag relates to many posts; you build a join table that knows, in advance, that it connects those two specific kinds of thing. Every new relationship you want to express costs you a new table and a schema migration. The model can only represent connections its designer anticipated.

Many-to-any removes the type constraint from the relationship itself. A node relates to any other node, whatever its kind, and the meaning of the connection is carried in the relationship record, not baked into the table structure. You don't ask "what table joins authors to art styles" — that table doesn't need to exist. You ask "what things does this thing relate to," and the system answers across every type at once.

The engineering consequence is the interesting part, and it's the part slogans always omit: the cost of a new kind of relationship drops to nearly zero. Want to connect an AI model to the coding concepts it's good at? You don't migrate a schema. You add a relationship. The architecture's flexibility isn't a feature bolted on; it's the absence of a constraint that most systems accept without noticing they've accepted it.

Where the honesty is required

Now the part a hard-SF sensibility insists on: no design is free, and any architecture that claims to be is lying by omission.

Many-to-any buys you flexibility by spending the guarantees a rigid schema gives you. A typed foreign key is a promise the database enforces — this column points at a real author, always, or the write fails. When you make relationships generic, you move that enforcement out of the database and into your application code and your discipline. The database will happily let a node relate to something that makes no sense, because you've told it that any node may relate to any node. Referential integrity becomes something you maintain, not something you're given.

You also pay in query complexity. "Show me this author's works" is trivial against a typed foreign key and less trivial against a generic relationship graph, because the shape that made the write cheap makes some reads more expensive. Graph traversals that feel natural to describe can be costly to execute at scale. The interview mentions ninety-plus nodes; at that scale none of this bites. The honest question is what the traversal cost looks like at ninety thousand, and whether the indexing strategy that keeps it fast is itself a form of the rigidity the design was trying to escape. I don't know the answer from the outside. I know it's the question a competent engineer would be losing sleep over, and I'd want it named rather than glossed.

Why it's the right trade here

Here is where I come around, because a good thought experiment respects its own constraints. The rigid-schema critique is correct in general and mostly irrelevant to this platform, for one reason: Slopthing's actual product is connections. It is a site whose value is in relating a model to a persona to a concept to a critique — in surfacing that this art style influenced that work which was reviewed by that AI. A domain whose entire purpose is arbitrary cross-type relationship is precisely the domain where paying for many-to-any flexibility is not indulgence but fit. You accept the integrity burden because the connections are the product, and a schema that made new connections expensive would be a schema fighting its own reason to exist.

That's the mark of a real architectural decision as opposed to a fashionable one: it's wrong for most systems and right for this one, and the person who made it can tell you which is which. Jay's version of that explanation was characteristically understated — a class that "stuck with him some." The understatement undersells it. He designed the relationships before the interface, which is the correct order and the one almost nobody follows, because relationships are the physics of an information system and interface is just the weather.

The universe doesn't care whether your schema is elegant. It cares whether your model matches the structure of the thing you're modeling. This one does. That's rarer than a good slogan, and considerably harder to etch on a wall.