on August 8, 2025
This week, I had a surprising comment on one of my posts. I wanted to address it because your data deserves more than just SQL and Prayers.
As you may know, I write a lot about product-oriented data engineering and management (PODEM), which includes data contracts, data products, Data Mesh, and the associated open standards from Bitol: ODCS and ODPS.
On one of my recently launched tutorials, I had the following comment from an anonymous reader:
It bothers me that this is basically a physical data model (DDL) with some extra tags. Most of the work is already done in the physical model, and you could simply add tags to the DDL to add this extra info.
Besides the physical pain associated with my eyes still bleeding, I gotta push back.
Sure, it looks like data contracts are DDL with a side of YAML dressing, but calling ODCS “just DDL + tags” is like calling a Rolls Royce “just a couch with wheels and an engine.”
Let’s unpack:
- DDL is a dialect soup. Every database speaks its own slightly-off version. Parsing DDL across platforms is like translating Shakespeare with Google Translate. It works, but it’s just not what you wanted.
- DDL (which is SQL) is great for telling databases what to do, but awful for telling humans and tools why or how it should be done. Try encoding team ownership, QoS, SLAs, or “talk to Bob before you drop this column” in DDL.
- Speaking of which: how exactly are you planning to cram things like support channels, pricing models, team roles, SLAs, server infra, and custom metadata into a CREATE TABLE statement? With comments? Good luck with that.
- Logical model? Logical types? DDL is blissfully unaware of your semantics — ODCS isn’t.
- And let’s not forget: not all data is relational. Events, APIs, files — they need love too. DDL won’t even swipe right on them.
I’m not saying ODCS and ODPS are perfect. But they exist because people (and entire companies) needed something better than a duct-taped CREATE TABLE. So we made it. Open, maintained, and community-driven.
Because if DDL were enough, I’d be spending my weekends playing LEGOs instead of designing YAML.
Curious what you think. Is DDL enough? Should contracts live in SQL? Or are we finally ready for something purpose-built? Drop a comment, I need to hear your take.
DDL Is Not a Data Contract was originally published in Data Mesh Learning on Medium, where people are continuing the conversation by highlighting and responding to this story.