⭐⭐ LA CUÑA — el catálogo gobernado sobre fuentes disgregadas

0 · El dolor, dicho como lo vive el cliente

No es «mis queries van lentas». Es:

Un cliente empresarial típico tiene, a la vez:

Nadie tiene UN almacén. Los tiene todos. Y el contexto que un agente necesita para responder bien vive repartido entre ellos, con permisos distintos en cada uno.

1 · La arquitectura, de punta a punta

[ Fuentes Disgregadas ] ──▶ ( Conectores Trino ) ──▶ [ Catálogo Gobernado Nativo ] ──▶ ( Proyección Ontológica ) ──▶ [ Grafo · Neo4j ] ──▶ [ Agentes · LLMs · Humanos ]
  S3 · Postgres · Kafka        abstracción                RBAC · linaje                   mapeo de entidades           latencia de ms
  Snowflake · Mongo · …        ZERO-COPY                  política · metadata                                          contexto

Cuatro propiedades, y ninguna es retórica:

1. No hay migración. Trino se enchufa donde el dato ya vive. El cliente no mueve un byte para empezar.
2. Una sola sintaxis. Todas las fuentes bajo un punto de acceso único, en SQL.
3. Onboarding en minutos. El cliente da credenciales y el catálogo mapea la metadata de la organización.
4. Y la que importa: la gobernanza es NUESTRA, no de cada fuente. El catálogo nativo aplica RBAC, linaje y política sobre fuentes heterogéneas — que es exactamente lo que ninguna de esas fuentes puede hacer por las demás.

2 · ⭐ Por qué Trino y no otra cosa: la arquitectura desacoplada por conectores

Adoptar Trino no fue comprar un motor rápido. Fue comprar una frontera de integración que ya existe y está mantenida por el ecosistema:

Eso es lo que convierte «el cliente tiene sus datos en siete sitios» de problema en característica. Y viene con su insignia de madurez en gobernanza y seguridad: no hay que construir el control de acceso por fuente, se hereda del punto único.

El equivalente sin Trino sería escribir un integrador por sistema, un mapeo de permisos por modelo de seguridad y un job de sincronización por fuente. Eso es lo que un equipo pequeño no puede permitirse — y es la razón presupuestaria, no estética, por la que la pila abierta es la palanca.

3 · ⭐⭐ La cuña frente a Stardog — y es ESTRUCTURAL, no de producto

Stardog apunta a un mercado parecido. La diferencia no es de calidad: es de dónde se apoyan.

Y simplifica la ecuación de forma desproporcionada para una plataforma cloud: donde el competidor necesita un integrador por almacén ajeno + un mapeo de permisos por modelo de seguridad + un job que siempre va tarde, nosotros no necesitamos ninguno de los tres.

4 · Lo que el cliente compra, dicho sin la palabra «plataforma»

No compra velocidad. Si quisiera velocidad o infraestructura de datos completa, se iría a Databricks o Snowflake, y haría bien. ⇒ no pasa nada por no igualarles en consulta analítica: ése no es el producto.

5 · 🔴 LO QUE ESTA CUÑA NO CUBRE TODAVÍA, y hay que decirlo

Un documento de posicionamiento que sólo lista fortalezas no sirve para decidir. Tres huecos medidos, no supuestos:

⚠️ ① Trino NO tiene conectores para el no estructurado

La lista de fuentes de §0 incluye «documentos, correos y PDFs en Google Workspace o Microsoft 365», y el diagrama los hace pasar por «Conectores de Trino». Eso hoy no existe.

El catálogo de conectores de Trino cubre fuentes tabulares o semi-estructuradas consultables: JDBC (Postgres, MySQL, SQL Server, Oracle, Snowflake, Redshift…), almacenes de objetos con formato tabular (Iceberg, Delta, Hive, Hudi), Kafka, MongoDB, Elasticsearch/OpenSearch, Cassandra, Pinot, Druid… y Google Sheets. No hay conector de Gmail, Drive, SharePoint, OneDrive ni PDF.

⇒ La mitad no estructurada de la cuña necesita OTRA vía de entrada — una ingesta que aterrice documentos como tablas y/o embeddings antes de que el catálogo pueda gobernarlos. Es trabajo real y no está hecho. Venderlo como «un conector más» sería prometer una pieza que no existe.

(Lo que sí es cierto y no cambia: una vez aterrizado, el gobierno y la proyección son los mismos. El hueco está en la puerta, no en la casa.)

⚠️ ② «Zero-copy» tiene un precio que aparece en producción

Federar sin mover datos es cierto y significa que cada query cruza la red hasta la fuente y compite con la carga operacional del cliente. Un JOIN entre su Postgres de producción y su lake lo paga su Postgres de producción. La respuesta de la industria es materializar lo caliente — o sea, acabar moviendo algunos datos, con criterio y medido. La promesa correcta es «no hay migración PARA EMPEZAR», no «no hay copia, nunca».

⚠️ ③ El pushdown decide si la federación es usable, y es por conector

Trino empuja filtros y agregaciones a la fuente cuando el conector lo soporta, y el soporte varía mucho entre conectores. Sin pushdown, un JOIN federado se trae la tabla entera por la red. ⇒ la calidad de la federación no es una propiedad de Trino: es una propiedad de CADA conector, y hay que medirla fuente a fuente antes de prometerla en una demo.

⚠️ ④ La cara gobernada cuesta ~3,4 s por query — y es TOPOLOGÍA, no diseño

Medido el 2026-08-07 desde el coordinador, aislando cada tramo:

La última fila es la que diagnostica. Listar tablas cuesta prácticamente lo mismo que leerlas ⇒ el coste no está en traer el dato de R2: está en la ida y vuelta al CATÁLOGO. Y la cadena cruza tres nubes:

Trino (GKE · europe-west1) → /api/iceberg (Vercel) → Lakekeeper (Railway) → R2 (WEUR)

⇒ ~3,4 s fijos por query, puramente por dónde está desplegada cada pieza. No es culpa de Trino (459 ms de suelo) ni de que la gobernanza viva en la cara —que es la decisión correcta y el diferencial del producto— sino de que la cara está lejos.

Por qué importa aquí y no en otro sitio: para el perfil batch/ELT que la proyección necesita, 3,4 s por query es irrelevante. Para la promesa de §1 —«onboarding en minutos» y la demo que la vende— una demo donde cada consulta tarda 4 segundos es una mala demo. Y para la federación de §5·③ se suma a cada fuente.

Es reducible sin tocar la arquitectura: co-locar la cara y el catálogo con el motor, y cachear metadata en el conector. No entra en ninguna fase todavía; se anota con número para que la decisión se tome con el dato y no con la sensación.

5·bis · 🔴 DECISIONES DEL OWNER — 2026-08-07

A · Las fuentes sin conector nativo de Trino quedan DEPRECADAS y sin soporte

excel · dynamodb · restapi · azure (CosmosDB) · hubspot · hbase. Por ahora. No es que falte configurarlas: no existe el conector. Con esto el alcance del catálogo queda acotado a lo que Trino sabe hablar, y el hueco §5·① deja de ser una promesa a medias y pasa a ser un límite declarado.

⚠️ Y con ello la mitad no estructurada de §0 sale del alcance inmediato: sin conector para Drive/Gmail/SharePoint/PDF, esa entrada necesita otro mecanismo que todavía no existe. Decir el límite es lo que permite venderlo sin mentir.

B · «Un catálogo por fuente conectada» es un error — pero el mecanismo no es el que parece

La intuición es correcta y el mecanismo hay que corregirlo, porque cambia qué se hace:

⇒ Lo que ellos tienen no es «muchas fuentes, un catálogo»: es que el catálogo de conector es un DETALLE DE IMPLEMENTACIÓN que el usuario nunca ve. El usuario ve una jerarquía catálogo.esquema.tabla con un solo modelo de gobernanza.

C · El techo real no era el número de catálogos: era el REINICIO

Y sí tiene solución. Verificado en la doc de Trino 470:

⇒ Corrige lo que el runbook daba por bloqueante: para federar bases de cliente (postgres/mysql/sqlserver) la fuga no aplica. Lo que queda en pie es la exposición de credenciales en el texto de la sentencia, que no se resuelve apagando la Web UI (la sentencia sigue yendo al log de queries) y es una decisión de riesgo, no técnica.

6 · Qué exige esto del roadmap, en orden

Con la cuña así, el orden deja de ser el del runbook de absorción y pasa a ser éste:

⚠️ Y una consecuencia de la decisión «Carbon SQL = Trino SQL» (ver platform-thesis.md): las 8 divergencias de dialecto se invierten. Dejan de ser «a Trino le faltan 8 cosas» 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. Ver lib/compute/dialect-divergence.ts.