SQL Is Everywhere, Which Is Exactly Why It Cannot Be the Center

Read enough data specifications and you notice how often they quote SQL inside themselves.

An Apache Ossie/OSI semantic model expresses a field's logic as an expression tagged with the SQL dialect it is written in. Warehouse platforms answer "what is in here?" with information_schema rows. Transformation tooling ships generated CREATE TABLE statements as its deliverable. Even formats with no relational ambitions borrow SQL's type words to be understood quickly.

SQL is the substrate the rest of the data world points at — and it is also, in practice, not one thing. Hold both facts at once and you can see where DDL belongs in a modern schema landscape, and why we built our SQL support neutral in the middle and explicit at the edges.

The most widely shared skill, the least portable artifact

Every data professional can read DDL. Almost no DDL runs unmodified on the next engine.

Identifier quoting is double quotes, backticks, or square brackets depending on where you are standing. A boolean is BOOLEAN, TINYINT(1), or BIT. A timestamp is TIMESTAMP, DATETIME, or DATETIME2. Text is VARCHAR until it is NVARCHAR. None of this is intellectually interesting, and all of it is load-bearing: it is the layer where a migration, a partner handover, or a "just run this against the reporting estate" turns into a week of work.

So "SQL" behaves less like a language than a family of closely related ones with a shared ancestor and irreconcilable spelling.

Tolerant on the way in, explicit on the way out

Our design rule for that family is deliberately asymmetric.

Decoding is dialect-tolerant. Import DDL and the coder accepts identifiers quoted in any of the three major styles, handles IF NOT EXISTS, strips line and block comments, reads schema-qualified table names, and understands multi-word types such as DOUBLE PRECISION and CHARACTER VARYING. It knows the type vocabulary real databases use rather than the standard's idealized subset: the serial types, MONEY, TIMESTAMPTZ, SMALLDATETIME, UUID, JSON, MySQL ENUM and SET. You should never have to normalize a dump before importing it.

Encoding is vendor-explicit. Export and you name the target — postgres by default, mysql, or sqlserver (we accept mssql too) — and the coder commits fully to it: correct quoting, vendor-correct types, inline ENUM where MySQL supports it, an honestly recorded VARCHAR fallback where the target does not. There is no "generic SQL" output mode, because generic SQL is a document that runs nowhere.

Between the tolerant entrance and the explicit exits sits a neutral model, and that neutrality is the point. A table imported from MySQL is not stored as MySQL stuff; it becomes Types, Elements, required flags, references, and vocabularies that owe nothing to any vendor's type system. The original SQL type text rides along so a round trip can reproduce it exactly, but the meaning is held in neutral form — which is what makes exporting to a different engine a translation rather than a rewrite.

What DDL composes with

Neutrality would be a modest virtue if SQL were the only format in the room. The same transform surface that speaks sql also speaks JSON Schema, Avro, JSON-LD, ShEx, OWL, LinkML, Protobuf, ODCS data contracts, Apache Ossie/OSI semantic models, MACH Alliance ODM entity documents, and the Sage Bionetworks Synapse profile — every one of them converting through the same neutral middle.

That is a hub rather than a mesh, and it changes the arithmetic. You do not need a SQL-to-Avro converter and a SQL-to-LinkML converter and a SQL-to-contract converter, each maintained separately with its own opinions. Each format needs exactly one translation — into and out of the middle — and inherits a path to all the others.

In practice this makes DDL a peer of formats it has never spoken to. A schema inherited from a decade-old relational system can arrive as CREATE TABLE statements and leave as an Avro record for a topic, a LinkML schema for a scientific pipeline, an ODCS contract for a data-product handshake, or an OWL ontology — and the reverse holds, so a schema born in LinkML or JSON Schema can be materialised as vendor-correct DDL for whichever engine operations actually runs. Records travel the same rails: instance data reads and writes as SQL INSERT statements alongside JSON, CSV, JSON-LD, and Avro.

Worth noting what we are not doing. We implement other people's published specifications — Bitol's Open Data Contract Standard, Apache Ossie/OSI, LinkML, the MACH Alliance ODM — rather than asking an ecosystem to adopt a format of ours. SQL DDL gets the same treatment: somebody else's well-established artifact, to be read and written faithfully, not improved.

The adjacent estate: catalogs, warehouses, and lakehouses

The sql format handles DDL as text. Next to it sits a surface for the platforms where SQL estates actually live.

Connectors for Databricks Unity Catalog, Snowflake, BigQuery, and Microsoft Fabric take the platform's own catalog exports — information_schema results, key listings, lineage rows — as uploaded artifacts and audit them against the governed model. No live credentials are held; the inputs are files the platform's tooling already produces. Going the other way, the Databricks connector emits Delta Lake CREATE TABLE IF NOT EXISTS DDL from the governed model, with nullability and keys derived from what the model says.

Different entry points, same principle: the relational world speaks many tongues, and the governed model is what they all translate through.

Why neutrality is not a philosophical preference

Every alternative to a neutral middle is a quiet commitment to somebody's dialect.

Standardize on the warehouse's DDL, and every downstream consumer inherits the warehouse's type approximations, including the ones it made because a column arrived from somewhere else. Standardize on one engine as "house SQL", and every export to the others becomes a hand-maintained port with its own drift. Standardize on a document — a wiki page, a dictionary spreadsheet — and you have chosen an artifact nothing enforces.

Neutrality is what keeps the choice of database an operational decision instead of a semantic one. You can adopt an engine, retire an engine, or run three at once through an acquisition, and the definitions your organization actually agreed on do not move. The DDL moves, because DDL is an output.

That is the position SQL DDL occupies here: a format with decades of production enforcement behind it, read tolerantly, written explicitly, and treated as one honest dialect-speaking citizen among many — never as the center, because the center belongs to meaning rather than to any vendor's grammar.

For the format list and the vendor options on SQL export, see the Schema Transformation guide in the CoreModels docs.