Definición: Anti-patron de rendimiento en el que una consulta inicial desencadena N consultas adicionales, degradando significativamente el rendimiento de la aplicacion.
— Fuente: NERVICO, Consultoría de Desarrollo de Producto
Que es el problema N+1
El problema N+1 es un anti-patron de rendimiento que ocurre cuando el codigo ejecuta una consulta inicial para obtener una lista de N registros y luego ejecuta una consulta adicional por cada uno de esos N registros para obtener datos relacionados. El resultado son N+1 consultas a la base de datos donde una o dos consultas bien disenadas habrian sido suficientes. Es una de las causas mas frecuentes de rendimiento deficiente en aplicaciones que utilizan ORMs.
Como funciona
El problema aparece tipicamente cuando se accede a relaciones de un modelo de datos de forma perezosa (lazy loading). Por ejemplo, al obtener una lista de 100 pedidos, el ORM ejecuta una consulta SELECT para cargar los pedidos. Cuando el codigo itera sobre los pedidos y accede al cliente de cada uno, el ORM ejecuta una nueva consulta SELECT por cada pedido para cargar el cliente asociado. El resultado son 101 consultas: 1 para los pedidos mas 100 para los clientes. Con eager loading o una consulta con JOIN, el mismo resultado se obtiene en 1 o 2 consultas. La diferencia en rendimiento puede ser de ordenes de magnitud, especialmente en listas grandes o conexiones de base de datos con latencia.
Por que importa
El problema N+1 es insidioso porque el codigo parece correcto y funciona bien con pocos registros en desarrollo. Los problemas aparecen en produccion cuando la lista crece: 10 registros generan 11 consultas (imperceptible), pero 1,000 registros generan 1,001 consultas que pueden tardar varios segundos. Cada consulta individual anade latencia de red, tiempo de parsing y overhead de conexion. En aplicaciones con multiples niveles de relaciones, el problema se multiplica exponencialmente. Es una fuente frecuente de deuda tecnica que se manifiesta como degradacion progresiva del rendimiento a medida que crecen los datos.
Ejemplo practico
Una API de e-commerce que devuelve un catalogo de productos con sus categorias tarda 3.2 segundos en responder cuando el catalogo tiene 500 productos. El equipo activa el logging de consultas SQL y descubre 501 consultas: una para cargar los productos y una por producto para cargar su categoria. La solucion consiste en modificar la consulta del ORM para usar eager loading (include en Sequelize, prefetch_related en Django, include en Prisma). Tras el cambio, la API ejecuta 2 consultas (una para productos, una para categorias) y responde en 80 milisegundos, una mejora del 97%.
Terminos relacionados
- Deuda tecnica - Consecuencia acumulada de no detectar y corregir problemas N+1 a tiempo
- Escalabilidad - Capacidad que el problema N+1 degrada significativamente a medida que crecen los datos
Ultima actualizacion: Febrero 2026