Skip to main content

What Is a Data Runtime?

CJ Cummings
CJ Cummings
Co-founder & CEO, Limitr

A data runtime is a system that executes data directly, the same way a JavaScript runtime executes JavaScript. Instead of treating data as an inert value that some separate program has to load and interpret, a data runtime runs documents that carry their own logic — fields, types, and functions together, in one place, sandboxed and portable across whatever host embeds it. Stof is a data runtime: a superset of JSON where the data validates itself, transforms itself, and acts.

That's the whole definition. Everything below is what it actually means in practice, and why the category needed a name in the first place.

Not a Format, Not a Language, Not a Database​

It's worth being precise about what a data runtime isn't, since the three nearest neighbors all miss something specific.

It's not a data format. JSON, YAML, and TOML describe a snapshot — inert the moment it lands, meaning nothing on its own until some other program decides what to do with it. A data runtime document is still just data structurally (Stof is a strict superset of JSON), but it doesn't stop there.

It's not a programming language, at least not in the general-purpose sense. There's no separate compilation step, no standalone executable, no notion of a "program" independent of the data it operates on. The logic exists specifically to serve the data it's attached to.

It's not a database. There's no query engine, no storage layer, no schema migration tooling. A data runtime document is a single, self-contained unit — closer to an object with methods than a table with rows.

What Actually Runs​

Concretely, valid JSON is already valid Stof:

{ "host": "0.0.0.0", "port": 8080 }

Add types and a function, and it's still the same document:

str host: "0.0.0.0"
int port: 8080

fn url() -> str { `http://${self.host}:${self.port}` }

url() isn't a separate script that knows how to read this config. It's part of the document, callable the same way a field is readable — doc.call('url') returns a real value, computed from data that lives right next to the function that computes it.

Why This Category Needed a Name​

Every interchange format describes a snapshot. The moment it crosses a wire, it's inert again on the other side, and whatever receives it has to already know, out of band, what to do with it. That's where schema drift comes from — a validation rule living in a separate file, or a separate service, that quietly stops matching the data it's supposed to describe. It's where "the API changed and nobody told the client" comes from. It's why nearly every serious system ends up bolting a DSL onto JSON or YAML eventually: Terraform invented HCL, GitHub Actions grew a custom expression language inside YAML, OpenAPI is JSON Schema with extensions piled on top.

None of those projects were wrong to need more than plain data. They just didn't have a runtime designed to hold both halves at once, so they built one, ad hoc, specific to their own tool. A data runtime is the general version of that same instinct — sandboxed by default, so logic that arrives from somewhere you don't control is safe to execute; portable, so the same document behaves identically whether it's running natively, in WebAssembly, or embedded in a Python host; and extensible, so a document can grow — parsing new fields, new types, even new functions into itself while it runs, instead of being a fixed shape someone has to redeploy to change.

FAQ​

Is a data runtime the same thing as a database? No. A database manages persistent storage, queries, and multi-record relationships. A data runtime document is a single self-contained unit of data and logic — no query engine, no storage layer of its own.

How is this different from a templating engine or a DSL? A templating engine or DSL is a separate tool that reads a document and produces an output. A data runtime document is the executable thing — the logic lives inside it, not in a separate interpreter built to understand it.

Is it safe to run a data runtime document from an untrusted source? That's the specific problem sandboxing solves. A well-built data runtime — Stof included — restricts a document to touching only what it's explicitly handed: no filesystem, no network, unless a host deliberately provides one. Logic arriving over the wire is safe to execute precisely because of that boundary.

Do I have to migrate my existing data to use one? Not with Stof specifically — it's a strict superset of JSON, so valid JSON is already a valid Stof document. Adopting it is a decision to add logic where you need it, not a migration.