Almacenamiento columnar: normalización extrema explicada

¿Por qué el almacenamiento columnar es en realidad normalización llevada al extremo?

Una base de datos columnar puede reducir el tiempo de ciertas consultas analíticas entre 10x y 50x frente a un sistema orientado a filas — y la razón detrás de ese salto de rendimiento no es magia de hardware, sino un principio de diseño que cualquier founder técnico ya conoce: la normalización.

El artículo publicado por Justin Jaffray en Buttondown propone una analogía que, una vez que la ves, no puedes desverla: guardar datos en columnas es estructuralmente equivalente a llevar la normalización relacional hasta su conclusión lógica. Aquí lo desmenuzamos con datos y contexto práctico para equipos de datos pequeños.

¿Cuál es la diferencia real entre almacenamiento por filas y almacenamiento columnar?

En un sistema orientado a filas (row-oriented), como PostgreSQL o MySQL, los datos se guardan secuencialmente fila a fila. Si tienes una tabla de usuarios con 50 columnas y quieres calcular el promedio de ingresos anuales, el motor debe leer las 50 columnas de cada fila para extraer solo la que necesita.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En un sistema columnar, como ClickHouse, DuckDB o BigQuery, cada columna se almacena de forma independiente. La misma consulta de promedio toca únicamente los bloques de disco donde vive esa columna — y nada más. Resultado: menos I/O, menos memoria, consultas más rápidas.

Hay otra ventaja casi invisible para quien no trabaja en datos: la compresión. Como una columna contiene valores del mismo tipo (todos enteros, todos fechas, todos strings con patrones similares), los algoritmos de compresión funcionan hasta 10 veces mejor que sobre filas heterogéneas. Menos espacio en disco equivale directamente a menos dinero en infraestructura cloud.

¿Cómo se conecta esto con la normalización relacional?

Aquí está el insight central que propone Jaffray: imagina que tomas una tabla relacional y la normalizas hasta el extremo. En lugar de una tabla con N columnas, creas N tablas de dos columnas cada una — un identificador de fila y el valor del atributo. Cada tabla representa un único atributo.

Eso es, conceptualmente, lo que hace un motor columnar. Cada columna se convierte en su propia estructura de almacenamiento con su propia clave implícita (el número de fila). Cuando quieres reconstruir una fila completa — o hacer un SELECT * — el motor ejecuta internamente algo análogo a un join entre todas esas estructuras.

¿La implicación práctica? Las operaciones que en SQL llamamos proyecciones (seleccionar solo ciertas columnas) son triviales en un modelo columnar porque ya están físicamente separadas. En cambio, las actualizaciones de filas individuales son más costosas, porque hay que escribir en múltiples ubicaciones. Por eso el modelo columnar domina en cargas OLAP (analítica, reportes, dashboards) y el modelo por filas sigue siendo rey en OLTP (transacciones, escrituras frecuentes).

¿Qué motores columnares están liderando el mercado en 2026?

El ecosistema de bases de datos columnares ha madurado significativamente. Estos son los actores clave que un equipo de datos moderno debería conocer:

DuckDB: motor OLAP embebido, corre en tu laptop sin infraestructura. Ideal para startups que necesitan analítica rápida sin pagar cloud. Reemplaza a Pandas en muchos flujos de trabajo de datos.
ClickHouse: diseñado para ingesta y consulta de datos a escala masiva. Cloudflare lo usa para analizar billones de eventos de red en tiempo real.
Apache Parquet + Apache Iceberg: no son motores de consulta sino formatos de almacenamiento columnar abiertos. Netflix usa Iceberg sobre S3 para gestionar petabytes con queries ad-hoc sin ETL complejo.
BigQuery (Google) y Snowflake: data warehouses serverless con separación de cómputo y almacenamiento. Dominan el mercado empresarial con cuotas de más del 40% combinado según proyecciones 2025.
Amazon Redshift: opción gestionada de AWS, con integración nativa con el ecosistema de datos de Amazon.

El mercado global de data warehouses columnares en cloud supera los 20.000 millones de dólares en 2025 y crece a más del 20% anual, impulsado por la adopción de IA y modelos analíticos en tiempo real.

¿Qué significa esto para tu startup?

Si tu equipo tiene menos de diez personas y manejas datos para dashboards, cohortes de usuarios, métricas de producto o análisis de comportamiento, es muy probable que estés usando la herramienta equivocada para esas cargas.

PostgreSQL es extraordinario para operaciones transaccionales — registrar un pedido, actualizar un perfil, manejar pagos. Pero si encima de ese mismo PostgreSQL estás corriendo consultas de analítica pesada, estás pagando un coste de rendimiento que no necesitas pagar.

Aquí van tres acciones concretas que puedes implementar esta semana:

Empieza con DuckDB para analítica local: si hoy usas pandas o consultas pesadas en Postgres para generar reportes, migra ese flujo a DuckDB. Es open source, corre en memoria, y puede leer directamente archivos CSV o Parquet sin configuración. Un equipo de una sola persona puede tener analítica de nivel enterprise en horas.
Adopta Parquet como formato de almacenamiento: si exportas o intercambias datos entre sistemas (pipelines de ETL, exportaciones de métricas, datasets de ML), cambia de CSV a Parquet. Compresión 5-10x mejor, lectura columnar nativa, compatible con prácticamente cualquier herramienta moderna del stack de datos.
Separa tu carga OLTP de tu carga OLAP: no intentes que una sola base de datos haga todo. PostgreSQL para transacciones, DuckDB o ClickHouse para analítica. Esta separación es uno de los patrones de arquitectura más rentables que puede implementar un equipo pequeño — y con herramientas modernas, el coste de mantener dos sistemas es mínimo.

¿Por qué los equipos pequeños tienen ventaja aquí?

Paradójicamente, las startups y equipos pequeños tienen una ventaja sobre las empresas grandes a la hora de adoptar almacenamiento columnar: no tienen deuda de arquitectura acumulada.

Una empresa con diez años de historia tiene miles de queries, aplicaciones y procesos atados a su base de datos transaccional. Migrar algo es una operación de meses con riesgo operativo real. Un equipo de cinco personas construyendo desde cero puede tomar la decisión correcta de arquitectura desde el día uno.

DuckDB es especialmente relevante para este escenario: equipos de uno a cinco personas que necesitan construir dashboards, pipelines de ML o análisis de cohortes sin contratar a un data engineer dedicado. Según benchmarks de la comunidad, DuckDB procesa consultas analíticas sobre datasets de millones de filas en segundos en hardware de laptop estándar — rendimiento que antes requería infraestructura cloud de cuatro o cinco cifras al mes.

El insight que cambia cómo ves tus datos

La analogía de Jaffray — almacenamiento columnar como normalización extrema — no es solo un ejercicio académico. Tiene implicaciones prácticas concretas sobre cómo diseñar tu stack de datos.

Si la normalización relacional te enseña a eliminar redundancia y separar responsabilidades entre tablas, el almacenamiento columnar aplica ese mismo principio al nivel físico de almacenamiento en disco. El resultado es un sistema que es brutalmente eficiente para las preguntas que los founders más necesitan responder: ¿cuántos usuarios activos tenemos este mes?, ¿cuál es el LTV por cohorte de adquisición?, ¿qué features correlacionan con retención?

Esas preguntas son analíticas, no transaccionales. Y para preguntas analíticas, el modelo columnar no es una optimización marginal — es la herramienta correcta desde el principio.