La frontera de la paridad SQL — hasta dónde, y por qué ahí
Decisión del owner (2026-08-03). «Hasta dónde llega la paridad SQL. Es la frontera que nos diferencia de los gigantes y conviene trazarla bien. Quien busca potencia SQL, profundidad en pipelines, notebooks o ML se va a Snowflake, Databricks o watsonx. Nosotros ofrecemos el lakehouse íntegramente gobernado y trazable como los líderes gracias al Index Catalog — pero las features del tratamiento del dato se orientan a la fabricación de data products (Pods) para IA.»
Este documento traza la línea sobre el backlog real (los 13 bloques), no en abstracto. Aplica el criterio de platform-thesis.md §3.
1 · La regla
Entra el SQL que produce o describe un data product.
Sale el SQL que administra un almacén.
Y un segundo test para los casos dudosos, que es el que de verdad resuelve:
Si la respuesta correcta a la pregunta es «esto debería ser automático», entonces no es una feature de SQL: es una política del Index Catalog.
Ese segundo test es lo que convierte la frontera de carencia en producto. Todo lo que cae fuera no desaparece — cambia de forma:
| Lo que un gigante te da como verbo | Lo que nosotros damos en su lugar |
|---|---|
OPTIMIZE / VACUUM | una política de compactación heredable (C1), disparada por uso (C2) |
ZORDER / CLUSTER BY / tuning de particiones | una política de layout adjunta al schema |
| Cachés, warehouse sizing, hints de plan | materialización decidida por el patrón de uso (C2) |
CREATE TASK / STREAM / dynamic table | frescura declarada como propiedad del Pod |
GRANT disperso por objeto | política adjunta y heredable por catálogo → schema → tabla |
Snowflake te da
OPTIMIZE. Nosotros te damos una política de compactación que se hereda y se dispara sola. No es menos superficie: es la misma decisión, movida de un verbo manual a una regla gobernada. Esa traducción es, literalmente, la propuesta de valor.
2 · La línea, sobre los 13 bloques
| # | Bloque | Veredicto | Por qué |
|---|---|---|---|
| 1 | Exploración y Análisis | ✅ DENTRO (hecho) | Sin ver el dato no se fabrica un Pod |
| 2 | Desarrollo de Consultas | ✅ DENTRO | Es la autoría del data product: joins, CTEs, ventanas, conformado |
| 3 | Gestión de Objetos (DDL) | ✅ DENTRO, recortado | Crear/alterar tabla y vista, sí. Tuning físico → política |
| 4 | Operaciones de Datos (DML) | ✅ DENTRO | Materializar la hidratación es el acto de fabricar |
| 5 | Consultas Parametrizadas | ⬆️ DENTRO — y SUBE | Un Pod parametrizado por entidad (Customer(id)) es una consulta parametrizada. Estaba infravalorado |
| 6 | Automatización y Scheduling | 🔄 REENCUADRADO | No como verbos SQL (TASK/STREAM/dynamic tables) sino como frescura declarada en el Pod. El scheduler es del Index Catalog, no del dialecto |
| 7 | Gobernanza y Seguridad | ⬆️ DENTRO — y SUBE | Es nuestro terreno: C1/C3 expresados en SQL. Aquí competimos de tú a tú |
| 8 | Testing y Validación | ⬆️⬆️ DENTRO — y SUBE MUCHO | Es lo que convierte el tier de afirmación en veredicto. Alimenta directamente la confianza del Pod. Hoy infra-construido |
| 9 | Integración con Carbon | ✅ DENTRO | Es el puente a las superficies que consumen |
| 10 | Funciones Avanzadas | ❌ FUERA, casi entero | UDFs en Java/Scala, ML en SQL, geoespacial, MATCH_RECOGNIZE, recursivas, series temporales. Es la década de Snowflake. Excepción: la función concreta que bloquee una hidratación real y medida |
| 11 | Exportación y Reporting | 🟡 RECORTADO | Exportar, sí — un Pod se consume. Reporting/BI, no: es el territorio de otros |
| 12 | Debugging | 🟡 MÍNIMO | Errores legibles y EXPLAIN comprensible para autorar. No tuning de planes |
| 13 | Prototipado | ✅ DENTRO | Es time-to-Pod con otro nombre |
Lo que esto reordena, y es lo valioso del ejercicio
Suben tres bloques que el plan tenía en el montón de en medio — 5, 7 y 8 — porque son los que hacen un Pod parametrizable, gobernado y verificable. Baja uno entero (10) y se reencuadra otro (6), que deja de ser dialecto y pasa a ser propiedad del Pod.
El bloque 8 es el que más cambia de peso. Hoy el tier medallón se afirma —12 de 112 datasets lo llevan— y nadie lo comprueba. Un Pod cuya calidad es una etiqueta sin respaldo es exactamente lo que un agente no puede usar para decidir. Testing y validación no es higiene de ingeniería: es la materia prima de la confianza que vendemos.
3 · Por qué esta línea nos diferencia en vez de dejarnos cortos
Los tres argumentos, por orden de fuerza:
① Competimos donde el rival no tiene ventaja acumulada. Diez años de optimizador y de funciones analíticas no se recuperan. Diez años de gobernanza aplicada al camino del dato para consumo agéntico no los tiene nadie, porque el problema es nuevo.
② Cada verbo que no implementamos se convierte en una política que ellos no tienen. §1. La lista de «fuera» no es una lista de carencias: es el inventario de lo que automatizamos.
③ La superficie que no construimos es presupuesto que va al Pod. Con un equipo pequeño, no hacer es la decisión de asignación más importante que existe.
4 · Los tres riesgos de trazarla aquí
| Riesgo | Cómo se acota |
|---|---|
| El muro en la demo — alguien pega una consulta de Snowflake y falla | El shim de dialecto se queda y el error dice qué falta y por qué. Un «no soportado» explicado no es un muro: es una frontera legible |
| La función que sí bloquea un caso real | Excepción explícita del bloque 10: entra la función que bloquee una hidratación medida, no la que se pida por completitud. El disparador es un Pod que no se puede fabricar, no una petición |
| La frontera se erosiona sola — siempre hay «una funcioncita más» | Cada excepción se anota con el Pod que la justificó. Sin Pod que la justifique, no entra. Es el mismo mecanismo del disparador de la compactación y del congelado de Karma |
5 · Cómo se aplica mañana
- Marcar en el README de los 13 bloques el veredicto de §2 — el plan y la frontera dejan de estar en documentos distintos.
- Reordenar: 5, 7 y 8 antes que 10, 11 y 12.
- Reescribir el bloque 6 como frescura del Pod, no como verbos de scheduling.
- En el bloque 3, separar el DDL de definición (dentro) del tuning físico (política).
Cruza con: platform-thesis.md (el criterio) · pod-critique.md (qué es un Pod y qué le falta) · index-catalog-sota.md (C1 hecha, C2 siguiente) · warehouse-sql/README.md (los 13 bloques).