Las migraciones ORM. Todos nos hemos fiado de ellas a tope, ¿no? Prisma, Drizzle: prometen un camino sin turbulencias del código a la base de datos, sin líos con SQL. Pero la semana pasada, un desarrollador clavó cuatro horas en una API que iba como tortuga, y el culpable era claro: una clave foránea sin índice. ¡Menuda sorpresa!
Lo que todos esperábamos era magia pura. Conectas tus relaciones en TypeScript, das a migrar y listo. ¿El vínculo Users-Orders? Resuelto. ¿Rendimiento? Problema de ellos, no tuyo. Hasta que las tablas crecen a millones de filas y las consultas van más lentas que internet de los 90.
Esto no es nuevo. En 2005, los de Hibernate ya se comían el mismo marrón. Los ORM abstraen el dolor, vale, pero a costa de cuellos de botella invisibles. La historia se repite: los creadores de herramientas priorizan la velocidad del dev sobre la realidad de la base de datos. ¿Y quién se frota las manos? Las empresas de ORM, con sus docs relucientes y upsells empresariales, mientras tu factura en la nube se dispara.
Pasé 4 horas la semana pasada depurando un endpoint de API lento. ¿El culpable? Un índice faltante en una clave foránea que mi ORM “amablemente” ocultó durante una migración de esquema.
En el clavo. Ese tuit lo clava. Los ORM añaden la restricción de clave foránea —ALTER TABLE “orders” ADD CONSTRAINT “fk_user” FOREIGN KEY (“user_id”) REFERENCES “users”(“id”);— pero se saltan el CREATE INDEX “idx_orders_user_id” ON “orders”(“user_id”);. ¿Por qué? Porque los índices son un “detalle de implementación”, dicen. Mentira. Sin ellos, Postgres hace escaneos secuenciales de toda la tabla Orders en cada consulta de usuario. Bien con 1K filas. Desastre con 10M.
Los desarrolladores miran schema.ts, no la base de datos real. ¿Relaciones? Enterradas en código. Sin mapa visual. Sin alertas. Caja negra lograda.
¿Por qué las migraciones ORM se saltan los índices una y otra vez?
Por pereza en los valores por defecto, simple. El motor de migraciones de Prisma da por hecho que optimizarás después… o que ni te enterarás. ¿Drizzle? Lo mismo. Generan la restricción para la integridad de datos, pero los índices son cosa tuya. Es como construir una autopista sin arcenes: aguanta hasta que llega el tráfico.
¿Y la excusa en los PR? “¡Gestión declarativa del esquema!” Bonito. Pero esconde la realidad relacional. El esqueleto de tu app —tablas, joins, escaneos— se pierde en archivos JS. He visto equipos lanzar a producción, celebrar deploys rápidos y luego ver la latencia multiplicarse por 100. ¿Alguien sorprendido?
Mi visión particular: esto huele al batacazo de la hype NoSQL en 2012. Todos abandonaron relaciones por “escala primero”, perdieron ACID y lo lamentaron. Los ORM son la versión relacional: escala después, reza más fuerte.
Aquí entra Tiger SQL. Visualizador de Postgres de código abierto, en el navegador. Pegas el esquema o conectas la base de datos, y zas: ERD con relaciones mapeadas. La IA detecta índices faltantes, consultas lentas. Sin gorduras, sin muros de pago. Búscalo en GitHub para forkearlo.
¿Cambia el juego? Un poco. Es un parche a la pereza de los ORM. Pero joder, hace que auditar esquemas sea pan comido. Ejecútalo local, ve los huecos antes de que producción explote.
¿Salvará Tiger SQL a tu equipo del infierno ORM?
Quizá. Es gratis, ligero, corre en el navegador. ¿ERD visuales? Al instante. ¿Optimización con IA? Alerta de índices B-Tree faltantes, columnas sin usar, hasta planes de consultas. Cero lock-in con vendors.
Pero seamos serios. Herramientas así salen todos los años. DbSchema, extensiones de pgAdmin: prometen lo mismo. ¿El as de Tiger? IA lista sin la factura de OpenAI, más pureza open source. Nadie se hace rico aquí; es para rascarse la picazón de un dev.
Lo probé yo mismo. Volqué un esquema de Prisma: el ERD iluminó user_id sin índice. Sugerencias de fix en segundos. Esa es la victoria: la visibilidad que los ORM robaron.
¿Escéptico? Forkea, ejecuta, demuéstralo. O quédate con migra
