InnoDB y su historia: De la adquisición de Oracle al duelo con MyISAM

Escrito el por griquelme
Facebook Twitter WhatsApp LinkedIn

La historia de InnoDB es un poco enredada, porque ha pasado por varias manos. Originalmente, InnoDB no era parte de MySQL. Fue desarrollado por una empresa finlandesa llamada Innobase Oy como un motor de almacenamiento independiente.

Diagrama mostrando la fusión de empresas tecnológicas entre Innobase Oy, Sun Microsystems y Oracle Corporation para controlar MySQL e InnoDB.
El complejo camino de propiedad que llevó a InnoDB a integrarse dentro de MySQL.

Luego ocurrió una cadena de adquisiciones que cambió el panorama. En 2005, Oracle Corporation compró Innobase Oy, controlando así el motor mientras MySQL seguía siendo propiedad de MySQL AB. En 2008, Sun Microsystems compró MySQL AB, y finalmente en 2010, Oracle compró a Sun. Hoy, InnoDB forma parte integral del proyecto MySQL.

Respecto a las otras bases de datos que usan esta maquinaria, prácticamente ninguna la usa directamente como código base. MariaDB desarrolló su propia variante llamada XtraDB y luego adoptó un InnoDB propio, mientras que sistemas como PostgreSQL o SQLite siempre utilizaron sus propios motores de almacenamiento completamente distintos.

El duelo de los motores: MyISAM vs InnoDB

Durante muchos años, la primera pregunta al crear una tabla era si usar MyISAM o InnoDB. Originalmente, MySQL permitía elegir entre varios motores como MyISAM, MEMORY y ARCHIVE.

Ilustración técnica mostrando las diferencias en los mecanismos de bloqueo entre los motores de almacenamiento MyISAM e InnoDB.
Comparativa visual entre el bloqueo tabular de MyISAM y el bloqueo por filas de InnoDB.

MyISAM era el motor original, muy rápido leyendo datos con archivos simples. Sin embargo, tenía un problema importante: si dos usuarios querían modificar la misma tabla, la tabla completa quedaba bloqueada. InnoDB fue diseñado para solucionar esto, introduciendo transacciones, integridad referencial y bloqueo por filas.

El precio de esta robustez es que InnoDB consume más RAM, espacio en disco y CPU. Hoy en día, con servidores potentes, ese coste suele ser irrelevante frente a las ventajas de la concurrencia y la recuperación tras fallos.