La tesis de plataforma — qué construimos, qué tomamos prestado, y por qué

⭐⭐ LA TESIS AFILADA — 2026-08-07 · LEER ESTO ANTES QUE NADA DE ABAJO

A · Qué compra el cliente, y qué NO compra

⇒ No pasa nada por no ser tan rápidos ni tan potentes que ellos en consulta analítica. No es una concesión ni una deuda: es que ése no es el producto, y perseguirlo sería competir en el eje donde el rival lleva una década.

Consecuencia inmediata y con euros detrás: el estándar de exigencia del catálogo no es «rápido como Snowflake». Es «completo, gobernado y PROYECTABLE». Son dos inversiones con un orden de magnitud de diferencia, y sólo la segunda está justificada.

B · No son dos productos: es uno que no vive sin su otra mitad

La crítica que este documento recibió —«describes dos productos: un lakehouse que compite con Databricks, y una capa de grafo donde no compite nadie»— está mal planteada, y el error es tratarlos como separables.

   ┌──────────────────────────────┐        ┌──────────────────────────────┐
   │  CATÁLOGO ENTERPRISE NATIVO  │  ────▶ │   GRAFO ONTOLÓGICO SEMÁNTICO │
   │  estructurado + no estruct.  │  proy. │   (motor propio: Memgraph,   │
   │  Trino · Iceberg · OPA/FGA   │  ont.  │    Neo4j o similar)          │
   │  lineaje · permisos · polít. │        │                              │
   └──────────────────────────────┘        └──────────────────────────────┘
        el dato y su gobernanza                 aquí viven los AGENTES,
        (nadie consulta aquí)                   los HUMANOS y los LLMs

Los agentes NUNCA piden nada al warehouse. Consumen del grafo, y el grafo tiene su propio motor. ⇒ ningún requisito de latencia agéntica recae sobre Trino, y ninguna comparación de velocidad analítica con Databricks decide nada.

C · ⭐ LA CUÑA, y es ESTRUCTURAL: Stardog proyecta sobre el catálogo de OTRO

Aquí está la razón de fondo por la que la capa 1 no es opcional ni es un lujo:

D · Qué le pide esto a Trino — y le sobra

Con el estándar corregido, el papel de Trino queda acotado y deja de estar en discusión:

Trino está SOBRADO para eso, no justo. El perfil que necesita la proyección es batch, no BI interactivo — y es en BI interactivo donde Photon, el liquid clustering y la caché de Snowflake marcan la diferencia que no vamos a igualar y no nos hace falta igualar.

D·bis · 🔴 DECISIÓN 2026-08-07 — Carbon SQL ES Trino SQL. DuckDB sale del mapa.

Del owner, y es coherente con todo lo anterior: al adoptar Trino como motor principal del warehouse, DuckDB queda colapsado. Sale de lectura y de escritura.

Consecuencia inmediata y limpia — las 8 divergencias se INVIERTEN. Dejan de ser «a Trino le faltan 8 cosas frente a DuckDB» y pasan a ser «nuestras superficies emiten dialecto DuckDB y tienen que emitir Trino». La lista blanca que hay que hacer cumplir es la de Trino, y las 5 marcadas traducir en dialect-divergence.ts pasan de «el shim traduce hacia Trino» a «la superficie deja de emitir dialecto DuckDB».

E · 🔴 Lo que esta sección ANULA en el repo

Documentos escritos antes de afilar la visión, que hoy confunden porque persiguen un objetivo que ya no es el objetivo:

⚠️ No se borran — son el registro de cómo se pensó, que es disciplina de este repo. Se marcan. Lo que hay que dejar de hacer es derivar roadmap de ellos.

0 · Mi pregunta estaba mal puesta

Pregunté si el dato del cliente aterriza en nuestro lakehouse o si gobernamos donde vive, como si fuera una decisión pendiente. Ya aterriza, de facto — y la arquitectura entera lo asume: la hidratación de un Pod pasa obligatoriamente por Junction, y Junction lee Iceberg.

Con eso, el argumento que sostenía a OpenMetadata —«su flota de 130+ conectores es el único foso real»— se cae solo: esos conectores catalogan sistemas que no servimos. Nosotros ya tenemos conectores de ingesta en el Data Gateway, que es otra cosa y es la que necesitamos.

La pregunta buena es la que puso el owner encima de la mesa: ¿es este modelo el óptimo para ganarse un nombre en la era agéntica?

1 · La trampa: «stack integral» es una descripción, no un objetivo

Snowflake y watsonx.data tienen un stack integral porque llevan una década y miles de ingenieros. Un equipo pequeño que persigue esa superficie no consigue un Snowflake pequeño: consigue un Snowflake peor, y compite en los ejes donde el otro lleva diez años de ventaja.

Y esa unidad ya está elegida en el norte, sólo que a veces la tapamos hablando de lakehouse:

Nadie vende la unidad que nosotros vendemos. Los grandes venden la tabla y ponen un agente delante; nosotros vendemos lo que el agente necesita realmente consumir. Ése es el nombre que se puede ganar.

2 · El lakehouse no es el producto — es lo que lo hace posible

Y por eso el modelo actual es el correcto, aunque a veces lo justifiquemos mal.

No se sostiene con «hace falta un lakehouse para ser una plataforma de datos» — eso invita a la comparación con Snowflake en los ejes de Snowflake, que perdemos. Se sostiene con esto, que ya está escrito en el norte §8: cuatro cosas que una capa semántica prestada sobre el almacén de otro no puede hacer:

1. hidratar a la granularidad que haga falta, sin pedir permiso;
2. materializar un Pod caliente cuando el uso lo justifique — decisión de plano de datos;
3. garantizar frescura y linaje, porque controlamos también la escritura;
4. aplicar la política en el plano de datos, no sólo en la API.

Un agente que actúa sobre un dato equivocado es peor que no tener agente. Las garantías son el producto, y las garantías exigen estar en el camino. Por eso poseemos el plano de datos: no por completismo, sino porque es la condición mínima para poder prometer algo.

3 · ⭐ El criterio que decide el roadmap

De lo anterior sale un test de una línea, aplicable a cualquier pieza de infraestructura:

Aplicado a lo que tenemos ahora mismo:

El caso incómodo, dicho claro

Karma es la pieza que más se parece a «construir Snowflake desde el principio». Los hechos, sin juicio: repo Rust aparte, karma-server desplegado y vivo, inerte (falta una env-var), con dos bloqueantes pendientes (el índice fuera del path servido y ningún harness diferencial que garantice que no diverge de PG). Mientras tanto, DuckDB ya cubre lectura y DML al 100 % y es el motor real del SQL Editor.

Contra el criterio: un motor propio no hace un Pod más rápido de fabricar, ni más fiable, ni más consumible — hasta que haya una consulta medida que DuckDB no aguante, y hoy no hay ninguna anotada. Eso no dice «mátalo»: dice congélalo con un disparador explícito, igual que se hizo con la compactación. Si la respuesta es «Karma es diferenciación técnica», entonces la pregunta honesta es si un equipo pequeño puede permitirse diferenciarse en el eje donde el rival tiene diez años y no en el eje donde no tiene nada.

4 · La posición de mercado: integral, pero abierto

Esto es lo que responde al «de forma clara y abierta» del owner, y no es una virtud declarativa: es a la vez el posicionamiento y la razón por la que un equipo pequeño puede permitirse ser integral.

Los grandes son integrales y CERRADOS. OpenMetadata y Collate son abiertos pero PARCIALES —sólo el plano de metadata—. Integral y abierto no lo ocupa nadie.

Y el punto práctico, que es el que importa para un equipo pequeño: cada spec de esa columna es un componente que no escribimos. Ser integral cuesta una fracción cuando cada capa es un estándar que otros mantienen. La apertura no es marketing — es la palanca presupuestaria.

Corolario que ya es invariante nuestro (el nº5 de Index Catalog), ahora extendido a toda la plataforma: conformarse a la spec, no depender del servicio. Emitimos OpenLineage aunque nadie lo consuma todavía; nuestros hechos llevan la forma de los JSON Schemas de OM aunque OM no esté desplegado. Eso mantiene reversible cada decisión de este documento, que es la única protección real cuando se decide rápido y con un equipo pequeño.

5 · La métrica: time-to-Pod

Si la propuesta de valor es fabricación rápida de data products, entonces la velocidad hay que medirla, o el roadmap se decide por opinión.

Es la métrica que ordena discusiones sin necesidad de autoridad: una pieza que la baja entra; una que no la toca, espera. Y tiene dos derivadas que ya sabemos medir con lo que estamos construyendo: cobertura (qué fracción de las preguntas cae en un Pod existente — el bucle de feedback del norte §7) y confianza (qué fracción de los Pods servidos tiene tier verificado, linaje completo y política aplicada — que es C1 + C2 + linaje + calidad).

6 · Qué decide esto sobre OpenMetadata

Con el dato aterrizando y el criterio de §3, el reparto queda así:

Y la secuencia, que importa tanto como la decisión: OM entrega algo real hoy (Trino + 120 tablas perfiladas) y el lado nativo aún no existe. Así que se deja de invertir en OM como autoridad de gobernanza ahora, se construye C2 + linaje + calidad nativos, y se retira su despliegue cuando el lado nativo conteste las mismas preguntas — no antes, o queda hueco. No es dejar un fallback: es no arrancar el suelo antes de poner el nuevo.

Y hay un acoplamiento que flipa con esto: N4. Hoy los Pods anclan por FQN a entidades de OM. Con Index Catalog nativo, anclan a coordenadas de Index Catalog. Cada Pod que nazca antes de decidirlo encarece el cambio — es la misma ventana que se cerró sola con el carrier de procedencia, y aquí todavía está abierta.

(Nota: la migración 20261265_semantic_context_graph.sql se marcó «no aplicar» cuando el espejo 1:1 de OM se dio por superado. Con esto vuelve a ser relevante — no como espejo de OM, sino como el modelo de metadata propio del Index Catalog. El trabajo no se tiró; cambia su justificación.)

7 · Lo que esta tesis no cambia

• El lakehouse se queda. No es overkill: es la condición de las cuatro garantías de §2. Lo que cambia es su justificación — soporte del Pod, no fin en sí mismo.
• El invariante del Index Catalog sale reforzado: guardar lo que el catálogo no puede saber es exactamente el trabajo que un Pod necesita.
• Junction sigue siendo la puerta única. Es lo que hace posible medir, gobernar y garantizar en un solo sitio — y con un equipo pequeño, un solo sitio no es elegancia: es viabilidad.
• Las decisiones ratificadas hoy (REST en Index Catalog · política en Index, aplicación en dos puntos) quedan intactas y encajan.

8 · ✅ Ratificado por el owner (2026-08-03)

1. Karma: CONGELADO, con disparador explícito — vuelve a la mesa cuando exista una consulta medida que DuckDB no aguante. No se mata: se para de invertir. Mismo mecanismo que la compactación.
2. time-to-Pod adoptado como métrica de PRIMERA CLASE. Con sus dos derivadas: cobertura y confianza.
3. La frontera de la paridad SQL: trazada → sql-parity-frontier.md. Regla: entra el SQL que produce o describe un data product; sale el SQL que administra un almacén. Reordena el backlog: suben los bloques 5, 7 y 8; sale el 10; se reencuadra el 6 (frescura del Pod, no verbos de scheduling).
4. N4: los Pods anclan a coordenadas del Index Catalog, no a FQNs de OpenMetadata. El om_fqn sobrevive como anotación opcional, nunca como identidad. Razón en §9.

9 · Por qué el anclaje del Pod es al Index Catalog (N4)

El anclaje decide una sola cosa, y lo decide para siempre: si la capa de Pods HEREDA la madurez del Index Catalog gratis, o si tiene que integrarse con todo dos veces.

Anclando a coordenadas del Index Catalog, el identificador de un atributo de Pod es un securable. Consecuencia directa: cada capacidad que el Index gana aterriza sobre los Pods sin fontanería nueva.

Anclando a FQNs de OpenMetadata pasan tres cosas, y las tres son malas:

1. Punteros colgantes por decisión propia. Acabamos de decidir que OM deja de ser autoridad de gobernanza; anclar la identidad del producto a un servicio que estamos retirando es construir la deuda a sabiendas.
2. Reintroduce el espejo de nombres. Un FQN es servicio.base.schema.tabla.columna: taxonomía editable. Es exactamente el defecto que costó la fase N·1 arreglar en el namespace físico, cuyo principio quedó escrito: el identificador debe espejar lo INMUTABLE, no lo EDITABLE. Repetirlo un nivel más arriba sería tropezar con la misma piedra, con mejor vista.
3. Dos autoridades en el camino caliente. La hidratación pasa por Junction, que resuelve por id de dataset. Anclar por FQN mete una traducción FQN→id en cada hidratación, y con ella una segunda fuente de verdad sobre qué objeto es cuál.