PostgreSQL
ORM y PostgreSQL
Uso de ORMs sobre PostgreSQL, sus ventajas para productividad y tipos y sus límites frente a SQL, transacciones, índices y capacidades específicas del motor.
- Última actualización
- Actualizada
- Nivel
- Aplicación
PostgreSQL
Uso de ORMs sobre PostgreSQL, sus ventajas para productividad y tipos y sus límites frente a SQL, transacciones, índices y capacidades específicas del motor.
Un ORM puede acelerar el desarrollo, pero no reemplaza el modelo relacional ni el conocimiento de PostgreSQL. La abstracción es útil mientras el equipo puede inspeccionar el SQL, controlar transacciones y conservar las garantías en la base.
Un ORM traduce operaciones del lenguaje a SQL y mapea filas a objetos. Existen varios niveles:
ORM de entidades
→ relaciones, unit of work, migrations
query builder tipado
→ SQL compuesto mediante API
generador desde schema/query
→ tipos cercanos al SQL
SQL manual
→ control directoNo existe una única elección correcta. Un proyecto puede combinar ORM para CRUD y SQL explícito para consultas críticas.
El valor disminuye cuando la consulta necesita features avanzadas que la abstracción expresa mal.
Define en PostgreSQL:
NOT NULL.CHECK.UNIQUE.Una validación del ORM protege un camino de aplicación; una constraint protege todos los writers y la concurrencia.
Inspecciona:
Activa logging controlado en desarrollo y usa tracing/pg_stat_statements en producción sin exponer secretos.
Código aparentemente inocente:
cargar 100 orders
→ acceder customer de cada una
→ 100 queries adicionalesSoluciones:
No cargues todo el grafo para evitar N+1; puede producir un producto cartesiano enorme.
Prefiere DTOs con columnas necesarias. Cargar entidades completas:
Una consulta de lectura no necesita siempre una entidad mutable.
La API del ORM debe garantizar una misma conexión durante el callback. No llames al cliente global desde dentro de una transacción si usa otra sesión.
Comprueba:
No asumas que una anotación convierte todo el request en una unidad segura.
El SQL generado puede:
CONCURRENTLY.Revisa cada migration y edítala cuando sea necesario. Usa expand-contract para producción.
Problemas típicos:
numeric convertido a number.bigint inconsistente.timestamp without time zone tratado como UTC.Prueba round trips y límites.
Una opción cascade: true del ORM no es necesariamente ON DELETE CASCADE de PostgreSQL. Puede ejecutar queries desde la aplicación y no proteger writers externos.
Distingue:
Comprende qué ocurre bajo concurrencia y grandes volúmenes.
Algunos ORMs soportan version columns. Verifica que el SQL incluya:
WHERE id = ? AND version = ?y que compruebe filas afectadas. Un campo updatedAt sin condición no evita lost updates.
El ORM puede emitir una query por fila o semántica distinta a ON CONFLICT. Revisa:
RETURNING.Para ingestión grande, SQL/COPY explícito suele ser mejor.
No abandones capacidades útiles porque el ORM no las modela cómodamente:
SKIP LOCKED.Usa migrations SQL y consultas raw parametrizadas encapsuladas.
Una escape hatch es saludable si:
Raw SQL no es fracaso del ORM; es reconocer el límite de la abstracción.
No uses simultáneamente synchronize: true y migrations controladas en producción. La aplicación no debe alterar schema automáticamente al arrancar.
Detecta drift comparando migrations aplicadas, introspección y entornos reproducibles.
El ORM sigue usando pool/driver. Configura presupuesto global y cierre. Instanciar el cliente repetidamente durante hot reload o invocations puede crear connection storms.
Mocks del repository no demuestran que el mapping o migration funcione.
Seguridad general de PostgreSQL reúne red, identidades, privilegios, datos, operación y recuperación en defensa por capas.