Durante las últimas décadas, el mundo de las bases de datos ha experimentado transformaciones profundas que reflejan la creciente complejidad de las necesidades empresariales y el avance imparable del hardware y la nube. En este contexto, el concepto de HTAP (Hybrid Transactional and Analytical Processing) surgió como una promesa tecnológica para cerrar la brecha entre las cargas transaccionales (OLTP) y analíticas (OLAP) dentro de un mismo sistema, pero hoy podemos afirmar con certeza que HTAP, tal como se concibió originalmente, ha muerto. Este fenómeno no representa un fracaso, sino una evolución natural que nos invita a repensar la forma en que manejamos y analizamos nuestros datos en la era moderna. Para entender la caída del HTAP es necesario viajar al pasado y recordar que durante los años ochenta las bases de datos relacionales cumplían un papel único y central. En aquella época, un solo sistema gestionaba tanto las transacciones diarias, como las consultas analíticas que se realizaban generalmente después de horas de actividad.
Esto era posible porque los conjuntos de datos eran manejables, el costo del cómputo era elevado y el almacenamiento limitado. Bajo estas circunstancias, no se necesitaba llamar HTAP a esta funcionalidad ya que simplemente, la base de datos hacía todo. Sin embargo, a medida que la década de los noventa avanzó, los negocios empezaron a generar y necesitar explorar volúmenes de información mucho mayores, planteando retos más complejos. Transacciones que exigían respuestas rápidas y puntuales entraban en conflicto directo con consultas analíticas que requerían escanear grandes cantidades de datos para obtener insights valiosos. Esta tensión técnica generó lo que se llamó “La Gran División”: la separación radical entre bases de datos para transacciones y bases de datos para análisis, un reflejo necesario para evitar que una carga de trabajo afectara negativamente a la otra.
El nuevo milenio consolidó esta separación a nivel tecnológico. Las bases de datos transaccionales se optimizaron para almacenamiento por filas permitiendo escrituras rápidas y consultas puntuales, mientras que las bases de datos analíticas adoptaron el almacenamiento columnar, ideal para escanear grandes conjuntos de datos y realizar agregaciones masivas eficientemente. Esta dualidad se convirtió en estándar industrial y fue respaldada por uno de los referentes del sector, Michael Stonebraker, quien definió claramente esta estrategia en su trabajo, declarando que la idea del “un tamaño para todos” había quedado obsoleta. Durante la década siguiente, la evolución de estas bases de datos adquirió matices distintos. Los sistemas distribuidos de OLTP adoptaron arquitecturas NoSQL que renunciaron al SQL tradicional y en muchos casos perdieron las propiedades ACID a favor de escalabilidad masiva.
Por su parte, la analítica evolucionó hacia arquitecturas basadas en lagos de datos y MapReduce, sacrificando la consistencia estricta para maximizar el rendimiento en procesamientos masivos. Sin embargo, la década de 2010 trajo una curiosa reconciliación. Por un lado, emergieron las bases de datos NewSQL que buscaban recuperar el control transaccional mediante SQL, y por otro, los almacenes de datos en la nube combinaban la capacidad analítica con garantías sólidas de consistencia. Ambos mundos, aunque atendiendo a cargas laborales muy diferentes, compartían principios arquitectónicos comunes como la distribución masiva y la ejecución paralela. La gran diferencia seguía siendo los motores de almacenamiento.
En este escenario, en 2014 apareció el término HTAP, definido por Gartner, como la gran evolución capaz de unir lo mejor de ambos mundos. HTAP buscaba reemplazar la lógica de dividir transacciones y análisis en sistemas separados con un enfoque unificado que fuera capaz de responder de manera rápida a necesidades operativas y analíticas simultáneamente. Inicialmente, proyectos como SingleStoreDB intentaron combinar filas en memoria para transacciones rápidas, con almacenamiento columnar para análisis pesados, demostrando cierta viabilidad técnica. Por otro lado, TiDB apostó por una combinación de motores trabajando en paralelo para atender cada tipo de carga. Pero pese a estos avances, el modelo HTAP no logró consolidarse en el mercado.
Durante la década de 2020, la tendencia fue clara: los almacenes de datos en la nube dominaron, mientras que las propuestas de NewSQL y HTAP permanecieron en un segundo plano. Las razones son múltiples y muy reveladoras. Reemplazar un sistema OLTP probado como Oracle o SQL Server es sumamente complejo y costoso, y la mayoría de las cargas transaccionales no requieren distribuciones complejas cuando una sola máquina potente es suficiente para manejar la carga, como lo ejemplifican empresas que optan por instancias individuales de PostgreSQL para sus aplicaciones críticas. Además, las arquitecturas cloud-nativas impulsaron un diseño basado en almacenamiento compartido y no compartido, prefiriendo almacenamientos de objetos flexibles y computación elástica en lugar de exigir discos rápidos y durabilidad en memoria. Este enfoque favorece la separación clara de responsabilidades y la modularidad, en contraste con la integración rígida que exige HTAP.
Otro aspecto fundamental tiene que ver con la estructura organizacional de muchas empresas. Las responsabilidades de OLTP suelen estar a cargo de los equipos de ingeniería de producto, enfocados en la rapidez y confiabilidad operativa, mientras que OLAP recae en los equipos de datos, concentrados en el análisis y generación de insights. Estas dinámicas, junto con sistemas de incentivos internos, ponen en jaque cualquier intento de consolidar ambas funcionalidades en un solo stack. La realidad actual muestra un ecosistema de datos en la nube que es modular y compuesto por diversos elementos especializados que cooperan en lugar de integrarse rígidamente. Este “HTAP por composición” implementa sistemas transaccionales y procesadores de streaming para capturar los cambios, formatos de tablas abiertas como Iceberg como motor de almacenamiento, motores de consulta distribuidos como Spark o Trino, y sistemas en tiempo real para índices y consultas ad-hoc.
En este nuevo paradigma, las preguntas cruciales giran en torno a cómo se aplica el log de escritura (WAL) a los lagos de datos, cómo se realiza la ingesta en tiempo real y cómo se aseguran índices sincronizados que permitan consultas rápidas y precisas sobre datos frescos. Hacer que los lagos o lakehouses sean verdaderamente capaces de responder en tiempo real representa el desafío actual y futuro, reemplazando la antigua batalla por consolidar OLTP y OLAP en un solo motor. Por lo tanto, podemos concluir que HTAP como concepto de base de datos unificada está muerto, pero su espíritu sigue vivo en las arquitecturas flexibles y distribuidas que componen hoy las infraestructuras modernas de datos. Este cambio de paradigma no reduce la urgencia de obtener análisis en tiempo real sobre datos transaccionales, sino que la aborda desde la colaboración de tecnologías especializadas y no desde una integración integral. El futuro de los datos en la nube pasa por la capacidad de ensamblar de manera eficiente componentes “best-in-class”, optimizados para sus tareas específicas, y asegurar que se comuniquen y sincronicen con rapidez y fiabilidad.
La innovación tecnológica se ha desplazado hacia resolver cómo estas piezas trabajan juntas, más que intentar crear un solo sistema que lo haga todo. En definitiva, entender que HTAP es una idea que ya no lidera el desarrollo tecnológico es una forma de adoptar la madurez del ecosistema de datos actual y prepararse para diseñar soluciones robustas y escalables que mejor respondan a las necesidades reales de negocio y técnicas en la era del cloud computing, donde la flexibilidad y modularidad son las claves para triunfar.
