El problema
En un data warehouse tradicional, cuando necesitás más capacidad de almacenamiento, tenés que agregar un nodo completo. Ese nodo viene con CPU, memoria y disco. Si lo que te faltaba era solo disco, igual pagás por todo lo demás.
Lo mismo pasa en la dirección contraria. Si tus queries son pesadas y necesitás más poder de procesamiento, pero el almacenamiento te sobra, no importa: tenés que agregar otro nodo completo, con todo el disco que no vas a usar.
Ese es el problema del acoplamiento entre cómputo y almacenamiento. No podés escalar uno sin escalar el otro.
Por qué funciona así
Los data warehouses tradicionales (Teradata, Vertica, y otros sistemas MPP de esa generación) distribuyen los datos en nodos para poder procesarlos en paralelo. Cada nodo tiene su porción de datos y su capacidad de cómputo. Cuando una query entra, se distribuye entre los nodos, cada uno procesa su parte, y después se consolida el resultado.
Esa arquitectura resolvía un problema real: las bases de datos relacionales clásicas corrían en una sola máquina, y cuando el volumen crecía, llegabas a un límite físico. No podías ponerle más disco o más CPU indefinidamente a un solo servidor.
El procesamiento distribuido rompió esa barrera. En lugar de una máquina gigante, podías tener muchas máquinas más accesibles trabajando en paralelo. En teoría, podías escalar casi infinito agregando nodos.
Pero el modelo tenía una restricción de diseño: los datos y el procesamiento vivían juntos en cada nodo. Si distribuías los datos en diez nodos, tenías diez unidades de cómputo. Si necesitabas veinte unidades de cómputo, tenías que tener veinte nodos con datos.
El impacto económico
El acoplamiento genera fricción económica. Pensá en dos escenarios comunes:
Escenario 1: mucho volumen, poco procesamiento. Tenés terabytes de datos históricos que querés conservar, pero las queries que corren son pocas y simples. Igual tenés que pagar por la capacidad de cómputo de todos los nodos donde guardás esos datos.
Escenario 2: poco volumen, mucho procesamiento. Tenés un dataset relativamente chico, pero las queries son complejas y concurrentes. Necesitás más poder de cómputo, pero para conseguirlo tenés que agregar nodos con almacenamiento que no vas a usar.
En ambos casos, pagás por recursos que no necesitás. Escalar estos sistemas implicaba agregar nodos completos, cada uno con una inversión significativa en hardware que no podías fraccionar.
Cómo se resolvió
La nube cambió las reglas. Con servicios como Amazon S3, el almacenamiento se volvió un recurso que podías escalar de forma independiente, a un costo mucho menor que el almacenamiento en nodos de cómputo.
Eso habilitó una arquitectura diferente: guardar los datos en object storage (barato, escalable) y levantar cómputo solo cuando lo necesitás. Si necesitás más almacenamiento, agregás almacenamiento. Si necesitás más cómputo, levantás más instancias de procesamiento. Los dos escalan por separado.
Esa separación es la base de los lakehouse y de los data warehouses modernos como Snowflake, BigQuery o Amazon Redshift. No es que el procesamiento distribuido haya dejado de existir; lo que cambió es que el almacenamiento ya no está atado al cómputo.
El costo de mover datos por red
El desacoplamiento tiene sus propios costos. Cuando los datos no viven en el mismo nodo que los procesa, hay que moverlos por la red. Y la red es el cuello de botella más lento en un sistema distribuido: más lenta que la memoria, más lenta que el disco.
Por eso los formatos columnares y la compresión importan tanto en estas arquitecturas. Si tenés que mover datos por la red, conviene que sean lo más chicos posible. Un archivo Parquet bien comprimido viaja mucho más rápido que datos crudos.
También cambia cómo pensás el diseño. En un data warehouse tradicional, el vendor te daba todo resuelto: almacenamiento, cómputo, motor de queries, todo integrado. En una arquitectura desacoplada, vos elegís cada pieza: dónde guardás los datos, qué motor usás para procesarlos, cómo los exponés para consumo.
Eso te da flexibilidad (podés cambiar el motor de cómputo sin migrar los datos), pero también te obliga a entender qué está pasando en cada capa.
En resumen
Los data warehouses tradicionales acoplan cómputo y almacenamiento porque así funcionaba el procesamiento distribuido de esa época. Eso generaba ineficiencias de costo cuando uno de los dos recursos escalaba más que el otro.
La nube permitió separar esas dos dimensiones. Hoy podés guardar datos en object storage barato y levantar cómputo solo cuando lo necesitás. Esa separación es lo que habilita las arquitecturas modernas.
Entender este trade-off te ayuda a evaluar cuándo tiene sentido un data warehouse tradicional (volumen moderado, carga predecible, preferencia por solución integrada) y cuándo conviene una arquitectura desacoplada (volumen grande, carga variable, necesidad de flexibilidad).