Cómo los ORMs simplifican el acceso a bases de datos — y qué pueden costar

Qué hace un ORM (y por qué a la gente le gusta)

Un ORM (Object–Relational Mapper) es una librería que permite a tu aplicación trabajar con datos de la base usando objetos y métodos familiares, en lugar de escribir SQL para cada operación. Defines modelos como User, Invoice u Order, y el ORM traduce acciones comunes—crear, leer, actualizar, borrar—en SQL detrás de escena.

El problema que resuelve: el “desajuste objeto vs. tabla”

Las aplicaciones suelen pensar en términos de objetos con relaciones anidadas. Las bases de datos almacenan datos en tablas con filas, columnas y claves foráneas. Esa brecha es el desajuste.

Por ejemplo, en código podrías querer:

• un objeto Customer
• que tiene muchas Orders
• cada Order tiene muchas LineItems

En una base relacional, eso son tres (o más) tablas enlazadas por IDs. Sin un ORM, a menudo escribes joins, mapeas filas a objetos y mantienes ese mapeo consistente a lo largo del código. Los ORMs empaquetan ese trabajo en convenciones y patrones reutilizables, para que puedas decir “dame este customer y sus orders” en el lenguaje de tu framework.

Por qué gustan los ORMs

Los ORMs pueden acelerar el desarrollo ofreciendo:

• Patrones consistentes de acceso a datos en el equipo
• Manejo más seguro de parámetros (reduciendo riesgo de inyección SQL cuando se usa correctamente)
• Manejo de relaciones incorporado (p. ej., customer.orders)
• Migraciones y herramientas de esquema en muchos ecosistemas

Una expectativa crucial

Un ORM reduce el código repetitivo de SQL y mapeo, pero no elimina la complejidad de la base de datos. Tu app sigue dependiendo de índices, planes de consulta, transacciones, locks y del SQL real que se ejecuta.

Los costos ocultos suelen aparecer a medida que el proyecto crece: sorpresas de rendimiento (consultas N+1, over-fetching, paginación ineficiente), dificultad para depurar cuando el SQL generado no es evidente, sobrecarga de esquema/migraciones, problemas de transacciones y concurrencia, y trade-offs de mantenimiento y portabilidad a largo plazo.

Las principales formas en que los ORMs simplifican el acceso a la base

Los ORMs simplifican la “plomería” del acceso a la base estandarizando cómo tu app lee y escribe datos.

CRUD orientado a modelos

La mayor ventaja es lo rápido que puedes hacer operaciones básicas de crear/leer/actualizar/borrar. En lugar de ensamblar cadenas SQL, enlazar parámetros y mapear filas de vuelta a objetos, normalmente:

• Creas una instancia del modelo y la guardas
• Recuperas registros como objetos modelo (a menudo con helpers de filtrado y orden)
• Actualizas campos y persistes cambios
• Eliminas un modelo por ID

Muchos equipos añaden una capa de repositorio o servicio sobre el ORM para mantener el acceso a datos consistente (por ejemplo, UserRepository.findActiveUsers()), lo que facilita las revisiones de código y reduce patrones de consultas ad-hoc.

Auto-mapeo de tipos, relaciones y validaciones

Los ORMs manejan mucha traducción mecánica:

• Mapeo de tipos: convertir tipos de BD (timestamps, decimals, enums) en tipos nativos
• Relaciones: definir “user has many orders” o “order belongs to user” y luego navegar esas relaciones en código
• Validaciones y constraints: hooks para campos requeridos, formatos y reglas de negocio antes de escribir datos

Esto reduce la cantidad de “pegamento fila-a-objeto” disperso por la aplicación.

Velocidad de desarrollador y herramientas compartidas

Los ORMs aumentan la productividad al reemplazar SQL repetitivo por una API de consultas más fácil de componer y refactorizar.

También suelen incluir características que los equipos de otro modo implementarían:

• Migraciones para versionar cambios de esquema
• Helpers de relaciones para enlazar y desenlazar registros
• Constructores de consultas/APIs para filtros, orden y agregados

Si se usan bien, estas convenciones crean una capa de acceso a datos consistente y legible en todo el código.

Abstracción: útil hasta que necesitas ver el SQL

Los ORMs se sienten amigables porque escribes principalmente en el lenguaje de tu aplicación—objetos, métodos y filtros—mientras el ORM convierte esas instrucciones en SQL detrás de escena. Ese paso de traducción es donde reside mucha conveniencia (y muchas sorpresas).

Cómo se genera el SQL

La mayoría de ORMs construye un “plan de consulta” interno desde tu código y luego lo compila en SQL con parámetros. Por ejemplo, una cadena como User.where(active: true).order(:created_at) podría convertirse en un SELECT ... WHERE active = $1 ORDER BY created_at.

El detalle importante: el ORM decide cómo expresar tu intención—qué tablas unir, cuándo usar subconsultas, cómo limitar resultados y si añadir consultas extra para asociaciones.

APIs de consulta del ORM vs SQL escrito a mano

Las APIs de consulta del ORM son excelentes para expresar operaciones comunes de forma segura y consistente. El SQL escrito a mano te da control directo sobre:

• Tipos y orden de joins
• Exactamente qué columnas se seleccionan
• Funciones específicas del SGBD (CTEs, window functions, hints)
• La forma del conjunto de resultados (especialmente para consultas de reporting)

Con un ORM, a menudo estás guiando en lugar de conducir.

“SQL lo suficientemente bueno” vs “el mejor SQL”

Para muchos endpoints, el ORM genera SQL que es perfectamente válido—los índices se usan, los resultados son pequeños y la latencia es baja. Pero cuando una página es lenta, “lo suficientemente bueno” deja de serlo.

La abstracción puede ocultar decisiones que importan: un índice compuesto faltante, un escaneo de tabla completo inesperado, un join que multiplica filas, o una consulta auto-generada que trae mucho más dato del necesario.

Cuando el rendimiento o la corrección importan, necesitas una forma de inspeccionar el SQL real y el plan de consulta. Si tu equipo trata la salida del ORM como invisible, perderás el momento en que la conveniencia se convierte silenciosamente en coste.

Trampa de rendimiento: consultas N+1 y acceso conversador accidental

Las consultas N+1 suelen comenzar como código “limpio” que se transforma silenciosamente en una prueba de estrés para la base.

Ejemplo estilo historia (usuarios + órdenes)

Imagina una página de administración que lista 50 usuarios y para cada usuario muestras la “fecha del último pedido”. Con un ORM es tentador escribir:

• Obtener usuarios: users = User.where(active: true).limit(50)
• Para cada usuario: user.orders.order(created_at: :desc).first

Eso se lee bien. Pero detrás de escenas a menudo se convierte en 1 consulta para usuarios + 50 consultas para orders. Eso es el “N+1”: una consulta para la lista y luego N consultas más para los datos relacionados.

Carga diferida vs carga anticipada (y cómo ambas pueden fallar)

Carga diferida (lazy loading) espera hasta que accedes a user.orders para ejecutar una consulta. Es conveniente, pero oculta el coste—especialmente dentro de bucles.

Carga anticipada (eager loading) precarga relaciones por adelantado (a menudo mediante joins o consultas separadas con IN (...)). Corrige N+1, pero puede salirte mal si precargas grafos enormes que no necesitas realmente, o si la carga anticipada crea un join masivo que duplica filas e infla la memoria.

Síntomas comunes

• Páginas que se ralentizan a medida que crece el tamaño de la lista
• CPU de base de datos alta con CPU de aplicación sorprendentemente baja
• Logs de consultas llenos de muchos SELECT pequeños y similares

Soluciones prácticas

Prefiere soluciones que coincidan con lo que la página realmente necesita:

• Precarga intencionalmente (solo las relaciones usadas en esa página)
• Agrupa búsquedas relacionadas (obtener orders para todos los usuarios visibles en una sola consulta)
• Selecciona solo los campos necesarios (evita SELECT * cuando solo necesitas timestamps o IDs)
• Mide y verifica: comprueba el log SQL antes y después; cuenta consultas por petición

Trampa de rendimiento: joins ineficientes, over-fetching y paginación

Los ORMs facilitan “incluir” datos relacionados. La trampa es que el SQL necesario para satisfacer esas APIs de conveniencia puede ser mucho más pesado de lo que esperas—especialmente cuando tu grafo de objetos crece.

Cuando los joins generados por el ORM se vuelven caros

Muchos ORMs usan por defecto unir múltiples tablas para hidratar un conjunto completo de objetos anidados. Eso puede producir conjuntos de resultados anchos, datos repetidos (la misma fila padre duplicada por muchas filas hijo) y joins que impiden al SGBD usar los mejores índices.

Una sorpresa común: una consulta que parece “cargar Order con Customer e Items” puede traducirse en varios joins más columnas extras que nunca pediste. El SQL es válido, pero el plan puede ser más lento que una consulta afinada a mano que une menos tablas o carga relaciones de forma más controlada.

Over-fetching: traer más de lo que usas

El over-fetching ocurre cuando tu código solicita una entidad y el ORM selecciona todas las columnas (y a veces relaciones) aunque solo necesites unos pocos campos para una vista de lista.

Los síntomas incluyen páginas lentas, uso elevado de memoria en la app y payloads de red mayores entre app y base. Es especialmente doloroso cuando una pantalla de “resumen” carga silenciosamente campos de texto completos, blobs o colecciones relacionadas muy grandes.

Paginación: trucos con OFFSET y conteos

La paginación basada en offset (LIMIT/OFFSET) puede degradarse a medida que crece el offset, porque la base puede escanear y descartar muchas filas.

Los helpers del ORM también pueden disparar consultas COUNT(*) costosas para “páginas totales”, a veces con joins que hacen los conteos incorrectos (duplicados) a menos que la consulta use DISTINCT cuidadosamente.

Remedios que mantienen la conveniencia

Usa proyecciones explícitas (selecciona solo columnas necesarias), revisa el SQL generado en la revisión de código y prefiere paginación por keyset (“método seek”) para conjuntos grandes. Cuando una consulta es crítica para el negocio, considera escribirla explícitamente (vía el query builder del ORM o SQL crudo) para controlar joins, columnas y comportamiento de paginación.

Costes de depuración: cuando el mensaje de error no basta

Los ORMs facilitan escribir código de base de datos sin pensar en SQL—hasta que algo falla. Entonces el error que recibes a menudo no describe el problema de la base de datos sino cómo el ORM intentó (y falló) traducir tu código.

Por qué los errores SQL son más difíciles de mapear a tu código

La base puede decir algo claro como “column does not exist” o “deadlock detected”, pero el ORM puede envolver eso en una excepción genérica (como QueryFailedError) ligada a un método de repositorio o una operación de modelo. Si varias funcionalidades comparten el mismo modelo o query builder, no es obvio qué sitio de llamada produjo el SQL fallido.

Para empeorar las cosas, una sola línea de código ORM puede expandirse en múltiples sentencias (joins implícitos, selects separados para relaciones, comportamiento de “check then insert”). Te quedas depurando un síntoma, no la consulta real.

Los stack traces pueden ocultar la consulta que falla

Muchos stack traces apuntan a archivos internos del ORM en lugar de tu código. El rastro muestra dónde el ORM notó el fallo, no dónde tu aplicación decidió ejecutar la consulta. Esa brecha crece cuando la carga diferida dispara consultas de forma indirecta—durante la serialización, renderizado de plantillas o incluso logging.

Activa el logging de SQL—con precaución

Habilita logging de SQL en desarrollo y staging para ver las consultas generadas y los parámetros. En producción, ten cuidado:

• Prefiere muestreo y logging solo de consultas lentas
• Redacta o evita registrar valores sensibles (emails, tokens, PII)
• Registra IDs de consulta/correlación para conectar una petición con su SQL

Usa herramientas de la base de datos para encontrar la causa real

Una vez que tienes el SQL, usa las herramientas de análisis del SGBD—EXPLAIN/ANALYZE—para ver si se usan índices y dónde se gasta el tiempo. Combina eso con logs de consultas lentas para capturar problemas que no lanzan errores pero degradan el rendimiento con el tiempo.

Costes de esquema y migraciones que no ves al principio

Los ORMs no solo generan consultas—también influyen silenciosamente en cómo se diseña y evoluciona tu base. Esos defaults pueden estar bien al principio, pero con el tiempo acumulan “deuda de esquema” que se vuelve cara cuando la app y los datos crecen.

Cómo los defaults del ORM moldean tu esquema

Muchos equipos aceptan migraciones generadas tal cual, lo que puede consolidar suposiciones cuestionables:

• Columnas nullable por defecto: convenientes en desarrollo, pero debilitan la calidad de datos y empujan validación a la app
• Índices faltantes o genéricos: los ORMs rara vez adivinan qué columnas necesitarán índice en producción, así que acabas con consultas lentas
• Constraints infrautilizados: unique, foreign keys y check constraints a veces se omiten para evitar fricción—hasta que aparecen duplicados o filas huérfanas

Un patrón común es construir modelos “flexibles” que luego requieren reglas más estrictas. Endurecer constraints después de meses de datos en producción es más difícil que fijarlos intencionadamente desde el día uno.

Deriva de migraciones y el problema de hotfixes

Las migraciones pueden desviarse entre entornos cuando:

• Alguien edita una migración después de haber sido aplicada en un lugar
• Se aplica un hotfix manual en producción
• Ramas diferentes introducen migraciones conflictivas

El resultado: staging y producción no son realmente idénticos y fallos aparecen solo durante despliegues.

Migraciones grandes: bloqueos y cambios de larga duración

Cambios grandes de esquema pueden crear riesgos de downtime. Añadir una columna con default, reescribir una tabla o cambiar un tipo puede bloquear tablas o ejecutarse lo bastante largo como para bloquear escrituras. Los ORMs pueden hacer que estos cambios parezcan inofensivos, pero la base aún tiene que hacer el trabajo pesado.

Buenas prácticas para reducir el coste

Trata las migraciones como código que vas a mantener:

• Revisa migraciones por constraints e índices (no solo cambios de modelo)
• Prueba en staging con volúmenes similares a producción
• Prefiere pasos reversibles e incrementales (patrones expand/contract) sobre un solo ALTER masivo
• Documenta cambios manuales y reconcílialos de inmediato para que el historial de migraciones siga siendo fiable

Sorpresas de transacciones y concurrencia

Los ORMs suelen hacer que las transacciones parezcan “manejadas”. Un helper como withTransaction() o una anotación del framework puede envolver tu código, autocommit en éxito y rollback automático en errores. Esa conveniencia es real—pero también facilita iniciar transacciones sin notarlo, mantenerlas abiertas demasiado tiempo o asumir que el ORM hace lo mismo que harías con SQL escrito a mano.

Helpers de transacción: fáciles de iniciar, fáciles de usar mal

Un uso común indebido es meter demasiado trabajo dentro de una transacción: llamadas a APIs, subidas de ficheros, envío de emails o cálculos costosos. El ORM no te impedirá hacerlo, y el resultado es una transacción de larga duración que mantiene locks más tiempo del esperado.

Las transacciones largas aumentan la probabilidad de:

• Deadlocks (dos peticiones esperando locks la una de la otra)
• Contención de locks (ralentizaciones que parecen problemas “aleatorios”)
• Timeouts y peticiones fallidas bajo carga

Unidad de trabajo y flushes implícitos: “¿por qué escribió en la BD?”

Muchos ORMs usan un patrón de unit-of-work: rastrean cambios en memoria y luego “flushean” esos cambios a la base. La sorpresa es que el flush puede ocurrir implícitamente—por ejemplo, antes de ejecutar una consulta, al hacer commit o al cerrar una sesión.

Eso puede llevar a escrituras inesperadas:

• Un endpoint “solo lectura” modifica accidentalmente un objeto y lo persiste silenciosamente.
• Una consulta dispara un auto-flush, enviando actualizaciones antes de lo esperado.
• La validación pasa localmente, pero la BD rechaza la escritura en el flush/commit (unique constraint, foreign key), lejos del código original que causó el cambio.

Lecturas inconsistentes y suposiciones de concurrencia

Los desarrolladores a veces asumen “lo cargué, no cambiará”. Pero otras transacciones pueden actualizar las mismas filas entre tu lectura y tu escritura a menos que hayas elegido un nivel de aislamiento y una estrategia de locking que coincidan con tus necesidades.

Los síntomas incluyen:

• Updates perdidos (dos usuarios se pisan mutuamente)
• Lecturas obsoletas (trabajar con valores antiguos)
• Bugs de concurrencia que “solo fallan en producción”

Orientación práctica

Mantén la conveniencia, pero añade disciplina:

• Mantén transacciones cortas: haz trabajo BD y sal de la transacción antes de llamar a servicios externos
• Haz límites explícitos: nombra claramente los scopes de transacción; evita defaults de “transaction everywhere”
• Controla el flushing: conoce cuándo tu ORM hace flush; usa sesiones/modos de solo lectura si están disponibles
• Añade una estrategia de reintento para fallos transitorios (deadlocks, errores de serialización): reintenta la transacción completa un número pequeño de veces con backoff

Si quieres una checklist más orientada a rendimiento, mira /blog/practical-orm-checklist.

Portabilidad y lock-in: trade-offs ocultos a largo plazo

La portabilidad es uno de los argumentos de venta de un ORM: escribe tus modelos una vez y apunta la app a otra base después. En la práctica, muchos equipos descubren una realidad más silenciosa—lock-in—donde piezas importantes de tu acceso a datos están atadas a un ORM y a menudo a una base de datos concreta.

Cómo se ve el “vendor lock-in” con ORMs

El lock-in no es solo sobre proveedor cloud. Con ORMs suele significar:

• Tu código depende de query builders, hooks de modelo y comportamiento de carga específicos del ORM
• Tu esquema, migraciones e incluso convenciones de nombres siguen las preferencias del ORM
• Cambiar de base rompe supuestos (tipos, índices, collations, comportamiento de constraints)

Aunque el ORM soporte múltiples bases, puede que hayas escrito al “subconjunto común” durante años—luego descubres que las abstracciones del ORM no mapean bien al nuevo motor.

Portabilidad vs usar bien la base de datos

Las bases son diferentes por una razón: ofrecen características que pueden hacer consultas más simples, rápidas o seguras. Los ORMs a menudo luchan por exponerlas bien.

Ejemplos comunes:

• Operaciones JSON (p. ej., consultar campos anidados, indexar rutas JSON)
• Window functions (rankings, totales acumulados, “top N por grupo”)
• Búsqueda de texto completo, índices especializados, columnas calculadas, índices parciales

Si evitas estas características para mantenerte “portable”, podrías terminar escribiendo más código de aplicación, ejecutando más consultas o aceptando peor rendimiento SQL. Si las adoptas, puedes salirte del camino cómodo del ORM y perder la portabilidad fácil que esperabas.

Enfoque pragmático: guarda vías de escape

Trata la portabilidad como una meta, no como una restricción que bloquee buen diseño de BD.

Un compromiso práctico es estandarizar en el ORM para CRUD cotidiano, pero permitir escape hatches donde importa:

• Usa SQL crudo (o APIs específicas del SGBD) para hot paths y reporting complejo
• Envuelve estas consultas detrás de una interfaz de repositorio/servicio pequeña para que el resto de la app permanezca limpio
• Añade tests que validen resultados y planes de consulta cuando el rendimiento sea crítico

Así mantienes la conveniencia del ORM para la mayoría del trabajo mientras aprovechas fortalezas de la base sin reescribir todo después.

Equipo y costes de mantenimiento: habilidades, revisiones y estándares

Los ORMs aceleran la entrega, pero también pueden retrasar habilidades importantes de base de datos. Ese retraso es un coste oculto: la factura llega después, normalmente cuando el tráfico crece, el volumen de datos aumenta o un incidente fuerza a mirar “bajo el capó”.

Habilidades que los ORMs pueden postergar

Cuando un equipo depende mucho de defaults del ORM, algunos fundamentos reciben menos práctica:

• Indexado: saber cuándo un índice faltante es el verdadero bug y cómo los índices compuestos afectan rendimiento
• Planificación de consultas: leer planes de ejecución para detectar scans completos, mal orden de joins o sorts costosos
• Diseño de esquema: elegir claves, constraints y tipos; diseñar para patrones de acceso comunes

No son temas “avanzados”, son higiene operacional básica. Pero los ORMs permiten lanzar features sin tocarlos por largo tiempo.

Cómo aparecen las brechas en incidentes o escalado

Las brechas de conocimiento suelen manifestarse de forma predecible:

• Durante un outage, la gente no puede responder rápido: “¿Qué consulta es lenta?” o “¿Qué índice ayudaría?”
• Los arreglos se vuelven conjeturas (tweak opciones del ORM, añadir caching) en vez de mejoras dirigidas
• Las revisiones se centran en lógica de aplicación, mientras los cambios de BD se cuelan sin estándares (nombres, migraciones, constraints)

Con el tiempo esto puede convertir el trabajo de BD en un cuello de botella especializado: una o dos personas son las únicas cómodas diagnosticando rendimiento de consultas y problemas de esquema.

Formación ligera y procesos de equipo

No necesitas que todos sean DBAs. Unos conocimientos básicos ayudan mucho:

• Enseña a los desarrolladores a ejecutar e interpretar un plan de consulta (p. ej., “¿dónde está el scan, cuál es el coste del join?”)
• Revisa normalización básica y cuándo la desnormalización es una decisión deliberada y medida
• Establece una “definición de hecho” para trabajo de datos: migraciones revisadas, índices considerados y planes de rollback

Añade un proceso simple: revisiones periódicas de consultas (mensuales o por release). Toma las consultas lentas top del monitoreo, revisa el SQL generado y acuerda un presupuesto de rendimiento (por ejemplo, “este endpoint debe mantenerse por debajo de X ms a Y filas”). Eso conserva la conveniencia del ORM sin convertir la base en una caja negra.

Alternativas y enfoques híbridos

Los ORMs no son blanco o negro. Si sientes los costes—problemas misteriosos de rendimiento, SQL difícil de controlar o fricción en migraciones—tienes varias opciones que mantienen productividad y recuperan control.

Opciones más allá de un ORM completo

Query builders (una API fluida que genera SQL) encajan bien cuando quieres parametrización segura y consultas componibles, pero aún necesitas razonar sobre joins, filtros e índices. Brillan en endpoints de reporting y páginas de búsqueda admin donde la forma de la consulta varía.

Mappers ligeros (micro-ORMs) mapean filas a objetos sin intentar gestionar relaciones, lazy loading o magia de unit-of-work. Son una buena elección para servicios mayormente read-only, consultas analíticas y jobs por lotes donde quieres SQL predecible y menos sorpresas.

Stored procedures ayudan cuando necesitas control estricto sobre planes de ejecución, permisos u operaciones multi-paso cerca de los datos. Se usan comúnmente para procesamiento batch de alto rendimiento o reporting complejo compartido entre apps—pero aumentan el acoplamiento a un SGBD y requieren buenas prácticas de revisión/testing.

SQL crudo es la vía de escape para los casos más duros: joins complejos, window functions, consultas recursivas y rutas sensibles al rendimiento.

Estrategia híbrida práctica

Un punto medio común: usa el ORM para CRUD y gestión de ciclo de vida, pero cambia a query builder o SQL crudo para lecturas complejas. Trata esas partes SQL-intensas como “consultas nombradas” con tests y propiedad clara.

Este principio se aplica también cuando aceleras con herramientas asistidas por IA: por ejemplo, si generas una app en Koder.ai (React en frontend, Go + PostgreSQL en backend, Flutter en móvil), aún quieres vías de escape claras para hot paths de base. Koder.ai puede acelerar scaffolding e iteración vía chat, pero la disciplina operacional sigue igual: inspecciona el SQL que emite tu ORM, mantiene las migraciones revisables y trata las consultas críticas como código de primera clase.

Factores para decidir

Elige según requisitos de rendimiento (latencia/debitaje), complejidad de consultas, frecuencia de cambios en la forma de las consultas, comodidad del equipo con SQL y necesidades operacionales como migraciones, observabilidad y debugging en on-call.

Checklist práctico: mantener la conveniencia del ORM sin el dolor

Los ORMs valen la pena cuando los tratas como una herramienta potente: rápidos para trabajo común, riesgosos cuando dejas de vigilar la hoja. La meta no es abandonar el ORM—es añadir hábitos que mantengan visible el rendimiento y la corrección.

1) Haz observable el trabajo de la base

• Registra SQL en desarrollo y staging (incluyendo parámetros cuando sea seguro). Si no ves el SQL, no puedes razonarlo.
• Mide conteos de consultas por petición/job. Añade un contador ligero y alerta sobre picos inesperados (señal clásica de N+1).
• Monitorea consultas lentas en producción usando el slow query log / performance insights del SGBD y vincula la consulta al endpoint o tarea en background.

2) Define guías de código que eviten sorpresas

Escribe un documento corto de equipo y aplícalo en revisiones:

• Evita lazy loading dentro de bucles. Si el código itera una lista, asume que disparará consultas extra salvo que se demuestre lo contrario.
• Limita el tamaño del “grafo eager”. Eager loading es útil, pero cargar árboles profundos puede causar joins enormes, duplicados o over-fetching.
• Selecciona solo lo que usas. Prefiere selección explícita de columnas para listados y APIs.
• Sé deliberado con la paginación. Define orden estable, evita offsets grandes y confirma que los índices soportan filtro + orden.

3) Testea el comportamiento de consultas, no solo la corrección

Añade un conjunto pequeño de tests de integración que:

• Aserten máximos de conteo de consultas para endpoints clave (p. ej., “la página índice debe quedarse bajo 10 consultas”).
• Validen la forma de las consultas en paths críticos (p. ej., sin scans completos; índices esperados usados).
• Mantengan presupuestos de rendimiento para jobs batch (tiempo y límite de consultas), especialmente después de upgrades de esquema u ORM.

Conclusión equilibrada

Mantén el ORM por productividad, consistencia y defaults más seguros—pero trata el SQL como una salida de primera clase. Cuando mides consultas, pones guardrails y pruebas los hot paths, obtienes la conveniencia sin pagar la factura oculta más adelante.

Si experimentas entrega rápida—ya sea en una base de código tradicional o en un flujo de trabajo vibe-coding como Koder.ai—esta checklist sigue igual: lanzar rápido es bueno, pero solo si mantienes la base observable y el SQL del ORM comprensible.