Open Standards
Data Landscape
An opinionated, interactive map of the open standards.
The open standards that power a modern data architecture, organised by what they describe. Inspired by the CNCF Landscape and the Deutschland Stack, and Simon's talk on open standards. Click any standard to learn more.
Definition — how data is described
API Interfaces
5
Data Products
4
Schema
5
Semantics
6
Storage — where data lives
File Formats
6
Open Table Formats
3
Storage Systems
2
Movement — how data flows between systems
Database Connectivity
3
Interconnection
2
Messaging
4
Transformation — how data is processed and reshaped
In-Memory Format
2
Processing
4
Discovery — how data is found and traced
Catalog APIs
5
Lineage
1
Operations — how data is queried, observed, governed
Query
2
Data Quality
3
Observability
2
Policies
1
AI Interfaces
2
FAQ
What's the origin story behind this Data Landscape?
It started as a single slide. Simon was preparing a talk on open standards for data mesh for the Data Mesh Belgium meetup in Leuven (April 2026), and wanted one picture that answered "which standards actually matter, and where do they fit?" Every existing diagram either flattened everything into one box or focused on a single vendor's stack.
The slide kept growing. After the talk, enough people asked for "the picture" that turning it into an interactive, linkable page made more sense than mailing around a PNG. Inspired by the CNCF Landscape and the Deutschland Stack, but narrower in scope: open standards only, no vendors.
Curated by Entropy Data. It's still a living view, and suggestions and corrections are welcome.
Why do you call this a data landscape? It is mostly about metadata standards, and it is of no help regarding vendor selection.
Guilty as charged. Most of what's here is metadata: schemas, contracts, lineage events, and catalog APIs all describe data rather than are data. We still call it the "Data Landscape" because that's the conversation people are having. When teams say "our data stack" they mean the standards, formats, and protocols around the data, not the bytes themselves.
It's also deliberately not a vendor landscape. There's no Snowflake vs Databricks, no "best catalog of 2026". The CNCF Landscape catalogues vendors and projects; this one catalogues the open standards they should interoperate around. If you're picking a vendor, ask which of these standards they implement. That's the question this landscape helps you ask, not answer.
Why did you include vendor specs in an overview of open standards?
Most "open standards" started as vendor specs. Iceberg came out of Netflix, Delta Lake out of Databricks, gRPC and Protobuf out of Google, OpenLineage was incubated at Datakin. What matters is whether the spec is openly governed and openly implementable today, not who wrote the first commit.
We include a spec when (a) the specification is published under an open license, (b) there are multiple independent implementations or a credible path to them, and (c) it's the de-facto standard for its slot in a modern data architecture. A spec that's effectively a single-vendor lock-in dressed as a standard doesn't make the cut, even if its repo is on GitHub.
The Status field in the drawer makes the governance situation explicit for each entry (foundation-hosted, vendor-led, draft, etc.), so you can judge for yourself.
Thank you
This landscape is curated by Entropy Data, with grateful thanks to everyone who helped shape it: Denis Arnaud, Benjamin Ditel, Stefan Negele, and Erik Wilde.
Missed a standard? Spotted something wrong?
This landscape is a living view — suggestions and corrections welcome.