Explora las ideas clave de Michael Stonebraker detrás de Ingres, Postgres y Vertica, y cómo moldearon las bases SQL, los motores analíticos y las pilas de datos actuales.
Michael Stonebraker es un científico informático cuyos proyectos no solo influyeron en la investigación de bases de datos: directamente moldearon los productos y los patrones de diseño que muchos equipos usan a diario. Si has usado una base de datos relacional, un almacén analítico o un sistema de streaming, te has beneficiado de ideas que él ayudó a demostrar, construir o popularizar.
Esto no es una biografía ni un recorrido académico por la teoría de bases de datos. En su lugar, conecta los sistemas principales de Stonebraker (como Ingres, Postgres y Vertica) con las decisiones que ves en las pilas de datos modernas:
Una base de datos moderna es cualquier sistema que pueda, de forma fiable:
Diferentes bases de datos optimizan estos objetivos de distinta manera—especialmente al comparar aplicaciones transaccionales, paneles BI y pipelines en tiempo real.
Nos centraremos en el impacto práctico: las ideas que aparecen en el mundo actual de “warehouse + lake + stream + microservices” y cómo influyen en lo que compras, construyes y operas. Espera explicaciones claras, compensaciones y consecuencias del mundo real—no una inmersión en demostraciones ni detalles de implementación.
La carrera de Stonebraker es más fácil de entender como una secuencia de sistemas construidos para trabajos específicos—y después ver cómo las mejores ideas migraron a productos comerciales.
Ingres comenzó como un proyecto académico que demostró que las bases de datos relacionales podían ser rápidas y prácticas, no solo teoría. Ayudó a popularizar las consultas al estilo SQL y el pensamiento de optimización basada en costos que más tarde se volvió habitual en motores comerciales.
Postgres (el sistema de investigación que dio lugar a PostgreSQL) exploró una apuesta distinta: las bases de datos no deberían ser de función fija. Deberías poder añadir nuevos tipos de datos, nuevos métodos de indexación y comportamientos más ricos sin reescribir todo el motor.
Muchas características “modernas” se remontan a esta era—tipos extensibles, funciones definidas por el usuario y una base de datos que puede adaptarse conforme cambian las cargas de trabajo.
A medida que creció la analítica, los sistemas orientados a filas sufrieron con grandes escaneos y agregaciones. Stonebraker impulsó el almacenamiento columnar y técnicas de ejecución relacionadas, orientadas a leer solo las columnas que necesitas y a comprimirlas bien—ideas ahora estándar en bases analíticas y almacenes en la nube.
Vertica llevó las ideas de investigación del columnar a un motor SQL MPP (procesamiento masivamente paralelo) comercialmente viable diseñado para consultas analíticas grandes. Este patrón se repite en la industria: un prototipo de investigación valida un concepto; un producto lo robustece para fiabilidad, herramientas y restricciones reales de clientes.
Trabajos posteriores se expandieron hacia el procesamiento de streams y motores específicos por carga de trabajo—argumentando que rara vez una base de datos generalista gana en todo.
Un prototipo se construye para probar una hipótesis rápidamente; un producto debe priorizar la operabilidad: actualizaciones, monitorización, seguridad, rendimiento predecible y soporte. La influencia de Stonebraker aparece porque muchas ideas de prototipo se graduaron a capacidades predeterminadas en bases de datos comerciales en vez de opciones marginales.
Ingres (acrónimo de INteractive Graphics REtrieval System) fue la prueba temprana de Stonebraker de que el modelo relacional podía ser más que una teoría elegante. En esa época, muchos sistemas se construían alrededor de métodos de acceso personalizados y caminos de datos específicos de la aplicación.
Ingres se propuso resolver un problema simple y orientado al negocio:
¿Cómo permites que la gente haga preguntas flexibles sobre los datos sin reescribir el software cada vez que cambia la pregunta?
Las bases relacionales prometían que podrías describir qué quieres (por ejemplo, “clientes en California con facturas vencidas”) en lugar de cómo recuperarlo paso a paso. Pero cumplir esa promesa requería un sistema que pudiera:
Ingres fue un paso importante hacia esa versión “práctica” de la computación relacional—una que podía correr en el hardware de la época y aún sentirse receptiva.
Ingres ayudó a popularizar la idea de que una base de datos debería hacer el trabajo duro de planificar consultas. En lugar de que los desarrolladores ajustaran manualmente cada acceso a datos, el sistema podía elegir estrategias como qué tabla leer primero, qué índices usar y cómo unir tablas.
Esto facilitó la difusión del pensamiento al estilo SQL: cuando puedes escribir consultas declarativas, iteras más rápido y más personas pueden hacer preguntas directamente—analistas, equipos de producto e incluso finanzas—sin esperar informes a medida.
La gran idea práctica es la optimización basada en costos: elegir el plan de consulta con el “coste” esperado más bajo (normalmente una mezcla de E/S, CPU y memoria), sobre la base de estadísticas de los datos.
Eso importa porque a menudo significa:
Ingres no inventó cada pieza de la optimización moderna, pero ayudó a establecer el patrón: SQL + un optimizador es lo que hace que los sistemas relacionales escalen de “buena idea” a herramienta diaria.
Las bases de datos relacionales tempranas tendían a asumir un conjunto fijo de tipos de datos (números, texto, fechas) y un conjunto fijo de operaciones (filtrar, unir, agregar). Eso funcionó bien—hasta que los equipos empezaron a almacenar nuevos tipos de información (geografía, logs, series temporales, identificadores específicos de dominio) o necesitaron características de rendimiento especializadas.
Con un diseño rígido, cada nuevo requisito se convierte en una mala elección: forzar los datos en blobs de texto, añadir un sistema aparte o esperar a que un proveedor añada soporte.
Postgres impulsó una idea distinta: una base de datos debe ser extensible—significa que puedes añadir nuevas capacidades de forma controlada, sin romper la seguridad y la corrección que esperas de SQL.
En lenguaje llano, la extensibilidad es como añadir accesorios certificados a una herramienta eléctrica en vez de rehacer el motor tú mismo. Puedes enseñar “nuevos trucos” a la base de datos, manteniendo transacciones, permisos y optimización trabajando como un conjunto coherente.
Esa mentalidad aparece claramente hoy en el ecosistema de PostgreSQL (y en muchos sistemas inspirados en Postgres). En vez de esperar una característica central, los equipos pueden adoptar extensiones validadas que se integran limpiamente con SQL y las herramientas operativas.
Ejemplos de alto nivel comunes incluyen:
La clave es que Postgres trató “cambiar lo que la base de datos puede hacer” como un objetivo de diseño—no como una ocurrencia tardía—y esa idea aún influye en cómo evolucionan las plataformas de datos modernas.
Las bases de datos no solo almacenan información—se aseguran de que la información se mantenga correcta, incluso cuando muchas cosas ocurren a la vez. Eso es para lo que sirven las transacciones y el control de concurrencia, y es una razón principal por la que los sistemas SQL se volvieron de confianza para trabajo real de negocio.
Una transacción es un grupo de cambios que debe tener éxito o fallar como unidad.
Si transfieres dinero entre cuentas, haces un pedido o actualizas inventario, no te puedes permitir resultados “a medias”. Una transacción asegura que no acabes con un pedido que cobró a un cliente pero no reservó stock—o con stock reducido sin registro de pedido.
En términos prácticos, las transacciones te dan:
Concurrencia significa que muchas personas (y apps) leen y modifican datos al mismo tiempo: pagos de clientes, agentes de soporte editando cuentas, jobs en segundo plano actualizando estados, analistas ejecutando informes.
Sin reglas cuidadosas, la concurrencia crea problemas como:
Un enfoque influyente es MVCC (Control de Concurrencia Multi-Versión). Conceptualmente, MVCC mantiene múltiples versiones de una fila por un tiempo corto, de modo que los lectores pueden seguir leyendo una instantánea estable mientras los escritores hacen actualizaciones.
El gran beneficio es que las lecturas no bloquean tanto las escrituras, y los escritores no se atrancan constantemente detrás de consultas de larga duración. Sigues obteniendo corrección, pero con menos esperas.
Las bases de datos actuales a menudo sirven cargas mixtas: muchas escrituras de la aplicación más lecturas frecuentes para dashboards, vistas de clientes y analítica operativa. Los sistemas SQL modernos recurren a técnicas como MVCC, bloqueo más inteligente y niveles de aislamiento para equilibrar velocidad y corrección—para que puedas escalar la actividad sin sacrificar la confianza en los datos.
Las bases orientadas a filas se construyeron para procesamiento transaccional: muchas lecturas y escrituras pequeñas, normalmente tocando un cliente, un pedido o una cuenta a la vez. Ese diseño es genial cuando necesitas recuperar o actualizar un registro completo rápidamente.
Piensa en una hoja de cálculo. Un row store es como archivar cada fila en su propia carpeta: cuando necesitas “todo sobre el Pedido #123”, sacas una carpeta y listo. Un column store es como archivar por columna: un cajón para “order_total”, otro para “order_date”, otro para “customer_region”.
Para analítica, rara vez necesitas toda la carpeta—sueles preguntar “¿Cuál fue el ingreso total por región el trimestre pasado?” Esa consulta puede tocar solo unos pocos campos a través de millones de registros.
Las consultas analíticas a menudo:\n\n- escanean grandes porciones de una tabla\n- usan solo un puñado de columnas\n- agregan (SUM/AVG/COUNT) y filtran mucho
Con almacenamiento columnar, el motor puede leer solo las columnas referenciadas en la consulta, saltándose el resto. Menos datos leídos del disco (y menos movidos por memoria) suele ser la mayor ganancia de rendimiento.
Las columnas tienden a tener valores repetitivos (regiones, estados, categorías). Eso las hace altamente compresibles—y la compresión puede acelerar la analítica porque el sistema lee menos bytes y a veces puede operar sobre datos comprimidos más eficientemente.
Los column stores marcaron el paso de bases OLTP-first hacia motores diseñados para analítica, donde el escaneo, la compresión y los agregados rápidos se convirtieron en objetivos primarios en lugar de consideraciones secundarias.
Vertica es uno de los ejemplos más claros de cómo las ideas de Stonebraker sobre bases analíticas se convirtieron en un producto que los equipos podían ejecutar en producción. Tomó lecciones del almacenamiento columnar y las emparejó con un diseño distribuido orientado a un problema específico: responder consultas SQL analíticas grandes rápido, incluso cuando los volúmenes de datos superan a un solo servidor.
MPP significa procesamiento masivamente paralelo. La forma más simple de pensarlo: muchas máquinas trabajan en una sola consulta SQL al mismo tiempo.
En lugar de que un servidor lea todos los datos y haga todo el agrupamiento y ordenamiento, los datos se dividen entre nodos. Cada nodo procesa su porción en paralelo y el sistema combina los resultados parciales en una respuesta final.
Así, una consulta que tardaría minutos en una sola máquina puede bajar a segundos cuando se reparte por un clúster—siempre que los datos estén bien distribuidos y la consulta sea paralelizables.
Sistemas analíticos al estilo Vertica brillan cuando tienes muchas filas y quieres escanear, filtrar y agregar eficientemente. Casos de uso típicos incluyen:
Los motores analíticos MPP no son un reemplazo directo para sistemas transaccionales (OLTP). Están optimizados para leer muchas filas y calcular resúmenes, no para manejar muchas actualizaciones pequeñas.
Eso conduce a compensaciones comunes:
La idea clave es el enfoque: Vertica y sistemas similares ganan velocidad afinando almacenamiento, compresión y ejecución paralela para analítica—aceptando restricciones que los sistemas transaccionales evitan.
Una base de datos puede “almacenar y consultar” datos y aun así sentirse lenta para analítica. La diferencia suele ser no el SQL que escribes, sino cómo lo ejecuta el motor: cómo lee páginas, mueve datos por la CPU, usa memoria y minimiza trabajo innecesario.
Los proyectos de Stonebraker enfocados en analítica impulsaron la idea de que el rendimiento de consultas es un problema de ejecución tanto como de almacenamiento. Este pensamiento ayudó a desplazar el enfoque desde optimizar accesos por fila hacia optimizar escaneos largos, joins y agregaciones sobre millones (o miles de millones) de filas.
Muchos motores antiguos procesan consultas “tupla a tupla” (fila por fila), lo que genera muchas llamadas de función y overhead. La ejecución vectorizada invierte ese modelo: el motor procesa un lote (un vector) de valores en un bucle ajustado.
En términos sencillos, es como mover la compra con un carro en lugar de llevar un artículo por viaje. El batching reduce overhead y permite que las CPU modernas hagan lo que mejor saben: bucles predecibles, menos ramas y mejor uso de caché.
Los motores analíticos rápidos se obsesionan con ser eficientes en CPU y caché. Las innovaciones de ejecución suelen centrarse en:
Estas ideas importan porque las consultas analíticas suelen estar limitadas por el ancho de banda de memoria y las faltas de caché, no por la velocidad bruta del disco.
Los almacenes de datos modernos y los motores SQL—almacenes en la nube, sistemas MPP y herramientas analíticas en proceso—frecuentemente usan ejecución vectorizada, operadores conscientes de compresión y pipelines cache-friendly como práctica estándar.
Incluso cuando los vendedores promocionan “autoscaling” o “separación de almacenamiento y cómputo”, la velocidad cotidiana que percibes sigue dependiendo en gran medida de estas elecciones de ejecución.
Si evalúas plataformas, pregunta no solo qué almacenan, sino cómo ejecutan joins y agregados internamente—y si su modelo de ejecución está pensado para analítica en lugar de cargas transaccionales.
Datos en streaming son simplemente datos que llegan continuamente como una secuencia de eventos—piensa en “acaba de ocurrir algo” mensajes. Un pago con tarjeta, una lectura de sensor, un clic en una página de producto, un escaneo de paquete, una línea de log: cada uno aparece en tiempo real y sigue llegando.
Las bases tradicionales y los pipelines por lotes son geniales cuando puedes esperar: cargar los datos de ayer, ejecutar informes, publicar dashboards. Pero las necesidades en tiempo real no esperan al siguiente job horario.
Si solo procesas datos en lotes, a menudo acabas con:
Los sistemas de streaming están diseñados alrededor de la idea de que los cálculos pueden correr continuamente a medida que llegan eventos.
Una consulta continua es como una consulta SQL que nunca “termina”. En lugar de devolver un resultado una vez, actualiza el resultado conforme llegan nuevos eventos.
Como los streams son no acotados (no terminan), los sistemas de streaming usan ventanas para hacer los cálculos manejables. Una ventana es una porción de tiempo o de eventos, como “los últimos 5 minutos”, “cada minuto” o “los últimos 1.000 eventos”. Esto te permite calcular recuentos móviles, promedios o top-N sin reprocesar todo.
El streaming en tiempo real es más valioso cuando el tiempo importa:
Stonebraker ha argumentado durante décadas que las bases de datos no deberían construirse todas como máquinas de propósito general que lo hacen todo. La razón es simple: distintas cargas de trabajo recompensan elecciones de diseño distintas. Si optimizas mucho para un trabajo (por ejemplo, actualizaciones transaccionales pequeñas), normalmente empeoras otro (como escanear miles de millones de filas para un informe).
La mayoría de pilas modernas usan más de un sistema de datos porque el negocio pide más de un tipo de respuesta:
Eso es “una talla no sirve para todo” en la práctica: eliges motores que coincidan con la forma del trabajo.
Usa este filtro rápido al elegir (o justificar) otro sistema:
Tener múltiples motores puede ser sano, pero solo cuando cada uno tiene una carga clara. Una herramienta nueva debe ganarse su lugar reduciendo coste, latencia o riesgo—no añadiendo novedad.
Prefiere menos sistemas con buena propiedad operativa, y retira componentes que no tengan un propósito nítido y medible.
Los hilos de investigación de Stonebraker—fundamentos relacionales, extensibilidad, almacenamientos columnar, ejecución MPP y “la herramienta correcta para la tarea”—se ven en las formas por defecto de las plataformas de datos modernas.
El warehouse refleja décadas de trabajo en optimización SQL, almacenamiento columnar y ejecución paralela. Cuando ves dashboards rápidos sobre tablas enormes, a menudo estás viendo formatos columnar junto con procesamiento vectorizado y escalado al estilo MPP.
El lakehouse toma ideas del warehouse (esquemas, estadísticas, caching, optimización basada en costos) pero las coloca sobre formatos de archivos abiertos y almacenamiento de objetos. El cambio a “el almacenamiento es barato, el cómputo es elástico” es nuevo; el pensamiento sobre consultas y transacciones debajo no lo es.
Sistemas analíticos MPP (clústeres compartidos-nada) son descendientes directos de investigación que demostró que puedes escalar SQL particionando datos, moviendo cómputo hacia los datos y gestionando cuidadosamente el movimiento de datos durante joins y agregaciones.
SQL se ha convertido en la interfaz común entre warehouses, motores MPP e incluso capas de consulta en lakes. Los equipos lo usan como:\n\n- un contrato estable para herramientas BI y analistas\n- una capa de portabilidad cuando cambian motores\n- una superficie de gobierno (vistas, permisos, acceso auditado)
Aunque la ejecución ocurra en distintos motores (batch, interactivo, streaming), SQL suele seguir siendo el lenguaje de cara al usuario.
El almacenamiento flexible no elimina la necesidad de estructura. Esquemas claros, significado documentado y evolución controlada reducen quiebres downstream.
El buen gobierno tiene menos que ver con burocracia y más con hacer los datos fiables: definiciones consistentes, ownership, controles de calidad y controles de acceso.
Al evaluar plataformas, pregunta:
La constante en la obra de Stonebraker es simple: las bases de datos funcionan mejor cuando están diseñadas para un trabajo específico—y cuando pueden evolucionar a medida que ese trabajo cambia.
Antes de comparar características, escribe qué necesitas realmente hacer:
Una regla útil: si no puedes describir tu carga en un par de frases (patrones de consulta, tamaño de datos, necesidades de latencia, concurrencia), acabarás comprando por palabras de moda.
Los equipos subestiman la frecuencia de cambios: nuevos tipos de datos, métricas nuevas, reglas de cumplimiento, nuevos consumidores.
Prefiere plataformas y modelos de datos que hagan el cambio rutinario en lugar de arriesgado:
Las respuestas rápidas solo valen si son las correctas. Al evaluar opciones, pregunta cómo el sistema maneja:
Haz una “prueba pequeña con tus datos”, no solo una demo:
Muchos consejos de bases de datos se quedan en “elige el motor correcto”, pero los equipos también tienen que entregar apps y herramientas internas alrededor de ese motor: paneles de administración, dashboards de métricas, servicios de ingestión y flujos administrativos.
Si quieres prototipar rápido sin reinventar todo el pipeline, una plataforma de "vibe-coding" como Koder.ai puede ayudarte a levantar apps web (React), servicios backend (Go + PostgreSQL) e incluso clientes móviles (Flutter) desde un flujo guiado por chat. Eso suele ser útil cuando iteras sobre diseño de esquemas, construyes un “producto de datos” interno pequeño o validas cómo se comporta realmente una carga antes de comprometer infraestructura a largo plazo.
Si quieres profundizar, busca almacenamiento columnar, MVCC, ejecución MPP y procesamiento de streams. Más explicaciones están en /blog.
Es un caso poco común donde sistemas de investigación se convirtieron en ADN de productos reales. Ideas demostradas en Ingres (SQL + optimización de consultas), Postgres (extensibilidad + pensamiento MVCC) y Vertica (columnar + analítica MPP) aparecen hoy en la forma en que se construyen y comercializan los almacenes, las bases OLTP y las plataformas de streaming.
SQL triunfó porque te permite describir qué quieres mientras la base de datos decide cómo obtenerlo de forma eficiente. Esa separación permitió:
Un optimizador basado en costos usa estadísticas de tablas para comparar planes de consulta posibles y elegir el de menor costo esperado (E/S, CPU, memoria). En la práctica, te ayuda a:
MVCC (Control de Concurrencia Multi-Versión) mantiene múltiples versiones de filas para que los lectores vean una instantánea consistente mientras los escritores actualizan. En términos cotidianos:
La extensibilidad permite que la base de datos crezca con nuevas capacidades—tipos, funciones, índices—sin forkear o reescribir el motor. Es útil cuando necesitas:
La regla operativa: trata las extensiones como dependencias—versiona, prueba actualizaciones y limita quién puede instalarlas.
Las bases orientadas a filas son excelentes cuando normalmente lees o escribes registros completos (OLTP). Las columnar brillan cuando exploras muchas filas pero tocas pocos campos (analítica).
Una heurística simple:
MPP (procesamiento masivamente paralelo) divide los datos entre nodos para que muchas máquinas ejecuten una sola consulta SQL en paralelo. Encaja bien con:
Cuidado con compensaciones como opciones de distribución de datos, costos de shuffle en joins y ergonomía más compleja para actualizaciones de alta frecuencia por fila.
La ejecución vectorizada procesa datos en lotes (vectores) en lugar de fila por fila, reduciendo overhead y usando mejor las caches de CPU. Normalmente se nota como:
Los sistemas por lotes ejecutan jobs periódicos, así que los datos “frescos” pueden retrasarse. Los sistemas de streaming tratan los eventos como entrada continua y calculan resultados incrementalmente.
Escenarios donde el streaming compensa:
Para acotar cálculos, el streaming usa ventanas (por ejemplo, últimos 5 minutos) en lugar de “todo el tiempo”.
Usa múltiples sistemas cuando cada uno tenga un límite de carga claro y un beneficio medible (coste, latencia, fiabilidad). Para evitar proliferación de herramientas:
Si necesitas un marco de selección, reutiliza la lista de verificación descrita en el artículo y piezas relacionadas en /blog.
