La escalera de aislamiento — cuánto aísla cada escalón y cuánto cuesta

Decisión de arquitectura, 2026-08-06. Cierra el §8·4 de
trino-first-viraje.md: ¿cluster por inquilino, si eso encarece
la infraestructura y tenemos plan gratuito?

La respuesta corta: «cluster por inquilino» y «coste por inquilino» NO son la misma
cosa, y tratarlas como si lo fueran es lo que hace que la pregunta parezca sin salida.
Hay cuatro escalones, no dos, y los precios están medidos.

Precios: los del catálogo de facturación real
(europe-west1, EUR, 730 h/mes). Los mecanismos de Trino, contrastados con su doc.

0 · Los dos hechos que deshacen el dilema

⭐ H1 · N `TrinoCluster` caben en UN cluster de Kubernetes

El cargo de gestión de GKE —63 €/mes, el sumando fijo más grande de la factura— se paga por cluster de Kubernetes, no por cluster de Trino. Un TrinoCluster es un CR del operador: un StatefulSet de coordinador + otro de workers, en su namespace.

⇒ Un TrinoCluster adicional cuesta exactamente sus pods. Cero infraestructura fija. La expresión «un cluster por inquilino» evoca un coste que en Kubernetes no existe.

⭐ H2 · Un cluster suspendido no cuesta nada, y así lo vende la industria

Starburst Galaxy —el Trino multi-tenant comercial— define el estado suspendido así: un pequeño conjunto de configuración y un mecanismo de escucha de peticiones, sin ningún nodo servidor activo y sin coste. Sus tiempos de auto-suspensión son 1, 5, 15, 30 min y 1 h — y para los clusters gratuitos sólo 1 y 5 min. El arranque en frío ronda los 5 minutos.

⇒ Galaxy resuelve el plan gratuito exactamente con el problema que nos preocupa: dando cluster dedicado y apagándolo agresivamente. La fricción del free plan no se paga en dinero: se paga en latencia de arranque.

1 · El mecanismo que faltaba en la conversación: Resource Groups

Es nativo de Trino, y su coste de infraestructura es cero. Aísla dentro de un cluster compartido:

Propiedad	Qué acota
`softMemoryLimit`	memoria distribuida antes de encolar — admite `%` de la del cluster
`hardConcurrencyLimit` (obligatoria) · `softConcurrencyLimit`	queries simultáneas
`softCpuLimit` · `hardCpuLimit`	tiempo de CPU por periodo
`maxQueued` (obligatoria)	profundidad de cola
`schedulingPolicy` (`fair`, `weighted_fair`, `weighted`, `query_priority`) + `schedulingWeight`	quién gana cuando hay contención — aquí es donde se expresa un plan de pago

Y dos capacidades que lo convierten en la respuesta al free plan:

Plantillas dinámicas. Los grupos se construyen con variables ${USER}, ${SOURCE} y capturas de regex ⇒ un grupo por inquilino sin escribir un grupo por inquilino.
⭐ Configuración en base de datos. El database resource group manager (MySQL, PostgreSQL, Oracle) recarga la configuración cada segundo y la aplica a las queries entrantes, sin reiniciar.

Lo que (2) significa para nosotros, y es grande

Nosotros ya tenemos Postgres: es Index. ⇒ dar de alta un inquilino con su cuota
de recursos es un INSERT, y surte efecto en un segundo. El alta no reinicia nada.

Es además la coherencia que este viraje persigue: Index es la fuente de política y el
motor la aplica — y aquí lo hace literalmente, leyendo de nuestra base de datos de
gobernanza.

⚠️ Y su límite, documentado, que hay que decir antes de apoyarse en él

trino#28373, abierto: los resource groups no limitan el número total de drivers. Un grupo con hardConcurrencyLimit: 5 puede tener 5 queries de 200+ drivers cada una y saturar los task slots del cluster entero, dejando sin servicio a los demás grupos.

⇒ Resource Groups acota memoria, concurrencia y CPU. NO garantiza aislamiento frente a un vecino ruidoso. Es un escalón real, no el último.

2 · La escalera — cuatro escalones, con precio

	Escalón	Aislamiento	Coste marginal por inquilino	Alta
E1	Cluster compartido + Resource Groups	memoria · concurrencia · CPU · prioridad. ⚠️ sin garantía frente a drivers	≈ 0 € (se prorratea)	`INSERT` en PG, 1 s, sin reinicio
E2	Clusters por PERFIL (interactivo · ETL · BI) + RG por inquilino dentro	+ aísla tipos de carga: un ETL pesado deja de envenenar lo interactivo	≈ 0 € (compartidos entre todos)	igual que E1
E3	`TrinoCluster` dedicado, SUSPENDIBLE	físico — JVM propia, memoria propia, fallo propio	≈ 0 € en reposo · sólo paga cuando corre	CR del operador + regla en el Gateway
E4	`TrinoCluster` dedicado, siempre caliente	físico + latencia predecible	desde ~68 €/mes (el coordinador) + workers	igual que E3

Los números, con los precios medidos:

E1/E2 · el pool compartido, para TODOS los inquilinos de free y pro
        1 coordinador n2-standard-4 on-demand ......... 136,91 €/mes
        2 workers   n2-standard-8 SPOT ................ 126,18 €/mes
        ───────────────────────────────────────────────────────────
        TOTAL ......................................... 263,09 €/mes
        entre 100 inquilinos .......................... 2,63 €/mes cada uno
        entre 500 inquilinos .......................... 0,53 €/mes cada uno

E3 · dedicado suspendible
        en reposo (suspendido) ........................ ~0 €/mes
        1 h/día de uso: coord n2-standard-2 + 2 workers n2-standard-8 spot
                        (68,46 + 126,18) × (1/24) ..... ~8 €/mes

E4 · dedicado siempre caliente
        coordinador n2-standard-2 on-demand ........... 68,46 €/mes
        + 2 workers n2-standard-8 SPOT ................ 126,18 €/mes
        ───────────────────────────────────────────────────────────
        TOTAL ......................................... 194,64 €/mes

El cargo de gestión de GKE (63 €/mes) NO aparece en ninguna fila porque se paga UNA
vez para toda la plataforma (H1). Es el sumando que hacía parecer prohibitivo el
cluster dedicado, y no aplica.

3 · La recomendación

Plan	Escalón	Por qué
Free	E1 — pool compartido, `schedulingWeight` bajo, `hardConcurrencyLimit` 1-2, `maxQueued` corto	Latencia cero y coste ~0,5-2,6 €/mes. Mejor experiencia que un dedicado suspendido (que costaría lo mismo pero con 5 min de arranque en frío), y para datos pequeños el aislamiento lógico basta
Pro	E1/E2 — mismo pool, `schedulingWeight` alto y límites mayores	El plan de pago se expresa en el peso del scheduler, no en hierro. Es exactamente para lo que existe `weighted_fair`
Business	E3 — dedicado suspendible	Aislamiento físico por ~8-30 €/mes reales. El escalón que hoy no estaba en la conversación y es el que deshace el dilema
Enterprise	E4 — dedicado caliente, y si hace falta su propio node pool	~195 €/mes de coste sobre un contrato enterprise es ruido. Aquí sí se vende aislamiento y latencia predecible

⭐ Y la consecuencia comercial, que es la parte bonita

La escalera de aislamiento ES la escalera de precios, y cada escalón tiene un
mecanismo técnico distinto y un coste real distinto. No hay que inventar diferenciación
artificial: «tu cluster no espera por nadie» y «tu cluster arranca en 5 s en vez de
5 min» son cosas que el cliente entiende y que cuestan de verdad.

Es, además, literalmente el modelo de Snowflake (virtual warehouses), de Databricks
(SQL warehouses serverless vs classic) y de Starburst Galaxy.

4 · Lo que sigue sin resolver: los CATÁLOGOS

Resource Groups resuelve el aislamiento de recursos sin reiniciar. No resuelve C5: un TrinoCatalog por inquilino sigue leyéndose al arrancar el coordinador.

Las tres salidas, y la buena es la tercera:


❌	`catalog.management=dynamic`	fuga de recursos con el conector Iceberg y loguea credenciales en la Web UI
⚠️	recargar el coordinador en cada alta	funciona con el blue/green del Gateway (sin downtime), pero es una operación por cliente
✅	el alta del catálogo es ASÍNCRONA y por lotes	recargar cada N minutos, no por alta. «Tu warehouse estará consultable en unos minutos» es una promesa perfectamente vendible — y el resto de la plataforma (Junction, la UI, la ingesta) funciona desde el segundo cero, porque no dependen de Trino

Y conviene ver el tamaño real antes de sufrir por ello: hoy son 8
organizaciones. Un cluster Trino aguanta decenas de catálogos sin despeinarse. Esto se
convierte en un problema con centenares — y para entonces el escalón E3/E4 ya habrá
sacado del pool compartido a los inquilinos grandes, que son precisamente los que más
catálogos mueven.

5 · Qué cambia en el roadmap

Fase	Qué añade esta decisión
F2·a	nada — sigue siendo un catálogo, un inquilino
F4 (OPA)	se empareja con Resource Groups: OPA dice qué filas puedes ver, RG dice cuánta máquina puedes usar. Son ejes distintos y hacen falta los dos
F5 (FTE + KEDA)	es también lo que hace posible E3 — sin scale-to-zero no hay «suspendido»
F6 (Gateway)	pasa a ser el conmutador de la escalera: enruta a pool o a dedicado, y despierta lo suspendido
Index	gana una tabla: la cuota de recursos por inquilino, servida al database resource group manager de Trino. Es Index siendo fuente de política, literal

6 · Las decisiones que quedan

¿Se acepta la escalera E1-E4 como modelo de aislamiento y de precios?
¿Free y Pro comparten pool y se diferencian sólo por schedulingWeight y límites? Es lo recomendado: cero infra nueva, y la diferenciación es real.
¿Index sirve la configuración de resource groups? Implica una tabla y exponerla al database resource group manager. [confirmar] que acepta un esquema de PG gestionado por nosotros o si impone el suyo.
[confirmar] el arranque en frío real de un TrinoCluster nuestro. Galaxy dice ~5 min; el nuestro es más pequeño y podría ser menos. Ese número decide si E3 vale para el plan Free, y sólo se sabe midiéndolo.

Cruza con: trino-first-viraje.md (§8·4, que esto cierra) · trino-gke-coste.md (los precios medidos) · f2-catalog-substrate-approach.md (C5) · ../runbooks/trino-absorcion.md (F4, F5, F6).