Post

The main idea is that every schema language it supports translates into one common graph format.

That means you can hand it two versions of a schema in any of the languages it supports, and it'll computes the diff, classify whether the change is breaking, and generate a converter that turns old records into new ones.

What's even better is that adding support for a new schema language just involves writing a description of it. Nothing about the underlying engine needs to change.

The generated converter goes both directions. The forward direction turns an old record into a new one; the backward direction converts it back, recovering whatever the forward path dropped (if anything) via a side channel called a complement.

29/4/26, 3:13 pm0 reposts0 likes

You can also ask what changed without generating a migration. Panproto classifies each diff entry as breaking or non-breaking, using the rules of the specific schema language. This classification can be run from the panproto CLI in CI to gate PRs that touch a schema before they reach review.

Very importantly, migrations are composable. You can chain v1 to v2 to v3 to v4 into a single converter that walks records all the way through. When auto-generation needs help on a particular field, you can drop in a value-level transform written in a small built-in expression language.

Everything above runs on the schema language-general graph. So the same machinery composes lenses across schema language boundaries, like OpenAPI to AsyncAPI or MongoDB to Cassandra.