CRÍTICA + INVESTIGACIÓN (2026-08-05). Nada implementado. Nace de una pregunta de
producto —«¿migramos por completo el warehouse a un motor distribuido multinodo (Trino o
StarRocks), aceptando la complejidad de clusters, réplicas y k8s, porque la visión es una
solución realmente enterprise sobre estándares abiertos?»— y de una premisa que hay que
corregir antes de decidir nada: «con Trino tendríamos aislamiento de credencial S3 por
tenant nativamente». No es cierto hoy, y la corrección juega a favor — pero no por donde
parece (§0).

Cruza con: duckdbengine.md (la decisión de motor vigente) ·
duck-server-tenant-warehouse-routing.md (el
enrutado que falta) · storage-vending-p4bis-approach.md
(la máquina de acuñar) · trino-openmetadata-warehouse.md
(Trino, que ya corre) · warehouse-index.md ·
carbon-sql-milestones.md · ../INFRA.md.

Memoria: duckdb-engine-decision, router-junction, platform-thesis,
warehouse-narrow-waist, warehouse-storage-perimeter.

⭐ La tesis de este documento

Nuestro activo no es el motor: es la cara. El aislamiento no vive en quién ejecuta el
SQL, sino en dónde se acuña la llave — y esa máquina ya es nuestra:
app/api/iceberg/v1/[...path]/route.ts

• lib/governance/storage-vending.ts.

De ahí se siguen las dos mitades de la conclusión, y conviene leerlas juntas porque una
sola engaña:

1. El motor es reemplazable ⇒ el salto es menos aterrador de lo que parece.
2. El salto no arregla la gobernanza por sí solo ⇒ tampoco es la bala de plata.

La lección: su fuerza no es el motor. Es que elasticidad y gobernanza son un solo
plano, con cero ops.

La lección: es literalmente el diseño que ya elegimos. UC vendiendo credenciales a
motores externos (DuckDB incluido) es nuestra cara abierta. La diferencia es madurez —
y que su motor escala.

Veredicto: candidato a capa de servicio (serving), jamás a sustrato abierto.

⚠️ Un dato de la industria que está desactualizado y conviene no repetir: la
comparativa de Onehouse
afirma que sólo Spark y Presto/Trino escriben formatos abiertos. StarRocks escribe
Iceberg desde la v3.1 (docs).

⭐ La lección de FORMA, que es la que hay que copiar

Nadie corre un cluster Trino. Corren clusters especializados por perfil de carga,
con un gateway delante. Lo que se compra no es «un motor distribuido»: es una flota.
Diseñar para un cluster único y descubrirlo después es el error caro.

🏁 P1 · CERRADO, DESPLEGADO Y VERIFICADO EN VIVO (2026-08-05) — ac3dad1

En producción (duck-production-ef4a…, JWT firmado, tabla real de bench):

SELECT * … LIMIT 3	200 · 3 filas · 10 columnas ⇒ la llave read-only llega a los bytes de R2
1 query sola	0,62 s
6 queries a la vez	0,83 s (serializadas: ~3,74 s)
pool tras la tanda	en_vuelo 0 · slots_perdidos 0 · cursores_libres 6 · storage_credential: read_only

⚠️ La lectura se comprueba con SELECT *, no con count(*) ni con /health?deep=1:
el conteo lo contesta la metadata del snapshot y el health cuenta tablas del catálogo.
Los dos dan verde con el acceso a los bytes roto — es la misma trampa que ya costó una
sesión con Trino («listar es catálogo, leer es storage»).

En frío, sobre la app ASGI real, el mismo experimento daba 6 en 3,71 s contra 4,13 s
una sola.

Qué cambió: la conexión única + lock se sustituye por un pool de cursores sobre la
misma instancia, acotado por semáforo (DUCK_MAX_CONCURRENT_QUERIES, default 8). La
conexión padre conserva el ATTACH, los SECRET y el contrato de dialecto, y el SQL
de usuario ya no corre en ella.

Cuatro cosas que salieron de medir en vez de suponer (services/duck-server/scripts/probe_cursor_pool.py):

1. interrupt() es por cursor y el cursor se reutiliza ⇒ un atasco pasa de matar
   el servicio a costar 1 slot de N, y si el hilo termina tarde el slot se recupera.
   wedged deja de ser una bandera y pasa a ser «se perdieron todos».
2. ⚠️ SET en el padre NO lo heredan los cursores; SET GLOBAL sí. Y
   duckdb_settings().scope no sirve para saberlo: describe de dónde viene el valor en
   vigor, así que dice GLOBAL en conexión limpia y LOCAL tras un SET. El contrato de
   dialecto ahora se declara global y se verifica sobre un cursor nuevo al arrancar:
   si no se hereda, el servicio no arranca.
3. 🔴 El pool NO arregla el radio de explosión. memory_limit es de la instancia: un
   SET desde cualquier cursor cambió el de todos (25 GiB → 190 MiB). El guard que saca
   PRAGMA/SET del read-path sigue siendo la única defensa — y ahora tiene número.
4. Una carrera que el pool habría abierto, cerrada de paso: el testigo de resolver()
   vivía en engine.ultimo_testigo y el router lo leía después. Con concurrencia real, la
   resolución de otra petición se cuela en medio y la sombra compara contra un testigo
   ajeno — sin romper nada visible, corrompiendo la cifra que gobierna el flip de M2c.
   Ahora el testigo se devuelve, no se guarda.

El otro techo, el invisible: los handlers llaman al motor con asyncio.to_thread, cuyo
executor por defecto es min(32, cpu+4) — 6 hilos en un contenedor de 2 vCPU. Subir el
semáforo a 8 y dejar ése en 6 habría mudado el cuello de botella a un sitio sin
fail-fast. Se dimensiona desde la misma cifra que el pool.

Estado: 221 tests verdes (tests/test_pool.py fija los cinco invariantes).

✅ P1b · la llave read-only — ya existe, y se probó que lo es

🔴 El paso B del perímetro se daba por hecho y no lo estaba. LAKEHOUSE_S3_RO_ACCESS_KEY_ID
tiene en Railway el mismo valor que la read-write: la variable existía, la capacidad no,
y el log decía «perimetro B». No se detectó porque la verificación del runbook ejecutaba
facade-smoke.ts, que escribe por ml-runner — medía que el escritor seguía escribiendo,
no que la llave de duck-server hubiera dejado de poder.

Lo hecho en código: el arranque compara las dos llaves y grita PERIMETRO ABIERTO;
/health publica storage_credential; y existe el control negativo
(scripts/storage/duck-ro-credential-gate.ts).

Token emitido y verificado el 2026-08-05 — puesto en .env.local y en Railway, y
pasado por el control negativo antes de confiar en él: 6 ✅ / 0 ❌.

① las dos llaves	distintas (1cbc1f… vs 34e79a…)
② la RO lee	LIST ✅ · GET ✅ · SELECT * en vivo ✅
③ ⭐ no escribe	PutObject → AccessDenied
④ ⭐ no borra	DeleteObject → AccessDenied

El orden importó: la credencial se midió antes de ponerla en producción. «Token de
sólo lectura» es una etiqueta; que no pueda escribir es un hecho, y sólo se sabe
intentándolo.

✅ P2 · HECHO Y DESPLEGADO (2026-08-05, cd9791e) — y APAGADO a propósito

duck-client.ts era el único de los tres clientes Node que no resolvía el inquilino.
Ya lo manda; duck-server lo comprueba y rechaza con 409 un warehouse que no
sirve, en vez de servir el compartido sin decirlo. Gate en vivo: 3 ✅ / 0 ❌.

Pero el enrutado nace apagado (DUCK_TENANT_WAREHOUSE_ROUTING), y el motivo está
medido: los ocho tenant_warehouses están active y vacíos. Encenderlo hoy
dejaría al único workspace con datos (112 datasets) sin ver ninguna tabla.

🔴 Lo que la sonda de P5 zanjó (scripts/storage/p5-register-table-probe.ts)

La pregunta era si mover un inquilino cuesta horas o semanas — es decir, si basta
re-registrar la tabla en el otro warehouse (metadata) o hay que copiar los bytes.
Medido con dos ubicaciones inexistentes, para no apostar 112 tablas vivas a una
lectura del contrato, y leyendo la diferencia entre los dos errores:

	resultado
① register con ubicación ajena (prefijo del compartido)	400 · «Provided location … is not a valid sublocation of the storage profile s3://lakehouse/test/w_7b5…»
② register con ubicación propia (control)	400 · «IO error … NotFound» — pasó la validación de ubicación

⇒ Lakekeeper valida el prefijo ANTES de leer la metadata. Re-registrar sin mover
datos es imposible. El control es lo que lo hace concluyente: sin ②, el primer
error podía ser del fichero y no de la ubicación.

La consecuencia real, y no es la que parecía: eso NO encarece a la vez las dos
salidas, las separa.

	¿cuesta copiar datos?
A · inquilino = warehouse (P1) — aislamiento en dos capas	sí, copia real
B · inquilino = primer nivel del namespace (w_<ws>.main.default, mismo warehouse)	no — la ubicación sigue siendo sublocation válida del compartido ⇒ metadata pura

B da posición al inquilino sin mover un byte; el aislamiento sigue apoyado en
autorización (una capa). A da aislamiento de verdad y cuesta una copia. La sonda no
elige: acota el precio de cada una, que es lo que faltaba para poder decidir.

⏰ Y una asimetría ARMADA, no disparada

El camino de escritura ya enruta al warehouse del inquilino (ingest-client.ts,
P3); el de lectura no (P2, apagado). Medido: 0 de 112 datasets nacidos después
de que existiera el warehouse — porque se creó hoy a las 07:10 y el último
dataset es del 3 de agosto. El primer dataset que se cree en ese workspace nacerá
donde el SQL Editor no mira. No es un riesgo futuro: es una cuenta atrás.

🏁 P2 · CERRADO (2026-08-05) — con la decisión de mapeo tomada

La decisión: un catálogo = un warehouse. Un schema = un namespace de UN nivel.

El error no era dónde están las tablas: era el nivel al que proyectamos. Metíamos
el catálogo dentro del namespace (main.default) y dejábamos el prefijo REST sin
usar. Los tres referentes coinciden en lo contrario:

Nivel	Databricks UC	Snowflake Open Catalog	Lakekeeper	Carbon (destino)
unidad de aislamiento, con storage propio	catálogo	catálogo	warehouse = {prefix}	catalogs de Index → un warehouse
agrupación lógica	schema	namespace	namespace	schemas de Index → namespace de 1 nivel
dato	tabla	tabla	tabla	tabla

Fuentes, y son prescriptivas, no interpretación:
«catalogs should be used as the primary unit of isolation» · «assign managed
storage at the catalog level for logical data isolation» · «Bind specific
catalogs to specific workspaces»
(UC best practices ·
managed storage).
UC lo expone tal cual en su cara Iceberg:
/v1/catalogs/<uc_catalog>/namespaces/<uc_schema>/tables/<t> — el catálogo ES el
prefijo. Y AWS lo dice desde el otro lado: el patrón pool es «un prefijo por
inquilino con la credencial fijada a él», que es exactamente el key-prefix de un
warehouse; el bridge (silo para quien lo exija, pool para el resto) es lo que ya
reserva §5 de storage-tenancy-approach.md para residencia o bucket del cliente.

La transformación, que es mecánica

  HOY      warehouse `lakehouse`  ·  namespace `main.default`  ·  ds_<uuid>
  DESTINO  warehouse del catálogo ·  namespace `default`       ·  ds_<uuid>
                    ▲                          ▲
           el `main` SUBE aquí        y desaparece de aquí

El primer nivel del namespace no se borra: asciende al prefijo. Por eso el
destino no inventa nada — reordena lo que ya existe.

⚠️ Un matiz que hay que dejar escrito ahora para no pagarlo luego: P1 nombró los
warehouses por workspace (carbon-<env>-w-<ws>), y la regla correcta es por
catálogo. Hoy coinciden —cada workspace tiene exactamente un catálogo, main,
medido— así que los warehouses de P1 sirven tal cual. El día que un workspace quiera
un segundo catálogo, ese catálogo necesita su propio warehouse, y el nombre
tendrá que llevar el catálogo, no el workspace. No se renombra hoy (renombrar un
warehouse es recrearlo); se registra la deuda.

Qué queda cerrado y qué no

✅ P2 (el enrutado) está hecho, desplegado y verificado — cd9791e, gate 3/0.
El campo viaja, duck-server rechaza con 409 lo que no sirve, y la palanca
DUCK_TENANT_WAREHOUSE_ROUTING espera.

🔜 Lo que falta es P5, y ya no es una incógnita: es un trabajo acotado. La sonda
midió que exige copia, y el volumen resultó ser 75,5 MB en 1.680 objetos — la
tabla mayor, 13,9 MB. La superficie real son 92 tablas, no 112: los 20 «sin
namespace» (18 vacíos) no están materializados en Iceberg y quedan fuera por
medición, no por borrado. Tramos: main.test (14, las activas) como canario,
luego main.default (78, ninguna tocada en 30 días).

Y no se recortan las tablas para abaratar el canario. El coste de esta migración
no son los bytes —son segundos— sino la superficie de corrección: los __row_index
legados, el default-sort-order-id que bloquea escrituras en las pre-D·4, las 5
vacías. Una migración validada sobre 3 tablas elegidas a mano es el fallo que ya
tenemos escrito: un instrumento que mide una copia no mide el sistema.

🔄 EL GATE ESTABA MAL FORMADO (corregido 2026-08-05)

El gate original era «una consulta MEDIDA que DuckDB no aguante». Mide hoy, no el
objetivo de diseño, y por eso está del revés: el volumen actual —75,5 MB— es una
decisión de producto, no una restricción. El sustrato tiene que estar
físicamente preparado para concurrencia masiva, al nivel de Snowflake o
ClickHouse, antes de que llegue la carga. Un gate que sólo dispara cuando ya duele
es reactivo; para una plataforma que se vende como enterprise desde el sustrato, no
sirve.

Se sustituye por los gates de trino-substrate-approach.md §5:
alcanzarlo por la vía correcta, identidad y política, y el tercer brazo del
comparador. Ninguno depende de cuántos datos haya hoy.

Lo que sí se conserva del razonamiento anterior es que la entrada de Trino no se
justifica por rendimiento, y hay que decirlo para no vender lo que no se ha medido —
«capability-check por fe» es exactamente lo que prohíbe junction.md §9 principio 12
(no nombrar capas que aún están huecas) y principio 11
(harness-diferencial-antes-de-servir).

Lo que sí apareció, midiendo P1 y P2, son dos límites estructurales que no se
arreglan esperando a tener más datos:

	El límite	Por qué Trino
① Tenencia	ATTACH es de la instancia de DuckDB, no de la conexión (medido en la sonda del pool). El alias lake no puede significar dos warehouses a la vez ⇒ un duck-server no puede servir a N inquilinos con warehouse propio — justo a donde va el sustrato tras P2	monta N catálogos en un proceso; es su modelo, no un apaño
② Gobernanza	duck-server se ata a Lakekeeper y se salta la cara (app/api/iceberg/v1)	Trino ya apunta a /api/iceberg ⇒ hereda grants, access_events y políticas sin configurar nada. Se nota: con los grants actuales ve 91 tablas y no 112, porque main.test se dejó sin conceder como control negativo

⇒ Trino es hoy el motor MÁS GOBERNADO que tenemos, no el más rápido. Ése es el
argumento de sustrato; el de rendimiento vendrá o no vendrá.

✅ Registrado e INERTE (lib/compute/engines/trino.ts)

Mismo criterio que Karma: available es un eje separado de sql/read, y un
motor no desplegado no puede mentir sobre sí mismo. Trino no publica ningún
puerto —hoy sólo le habla la ingesta de OpenMetadata por la red interna de Docker—
así que sin TRINO_URL declara available: false con el motivo, getSqlEngine
lanza EngineUnavailableError (despliegue, no capacidad) y availableSqlEngines()
no lo incluye. write: false a propósito: el escritor del Warehouse es uno y sólo
uno, y la ACL read-only es una de las tres capas que protegen esa invariante.

⛔ Y el Trino de la VM de OpenMetadata NO es el camino

Es un docker-compose sin puerto publicado, sin autenticación, sin TLS y sin
aislamiento, montado para que el perfilado de OM tuviera números. Cumplió su función
y es legacy. Absorberlo como motor principal desde ahí sería heredar sus
limitaciones y llamarlo arquitectura.

La vía correcta está en trino-substrate-approach.md:
operador en Kubernetes (TrinoCluster + TrinoCatalog como CRDs — que es justo lo
que hace declarativo «un catálogo por warehouse de inquilino»), Trino Gateway
delante, TLS + shared secret + OIDC contra el Keycloak que ya tenemos, OPA para
row-filters y column-masks (con el bridge oficial de Lakekeeper), FTE con exchange
manager y autoescalado por cola. Fases T1-T5 con sus gates.

La visión —enterprise, abierta, vanguardista— no la entrega el motor distribuido.

La entregan la cara Iceberg REST, el Index y el vending, que ya existen y ya funcionan.

El motor distribuido entrega escala y concurrencia — que es un problema real, medible,
y que hoy tenemos en 1.