ORM vs SQL Puro 🪑

El eterno debate, donde unos defienden la "comodidad" y otros el "control".

🪑 Silla nº1: SQLAlchemy ORM

ORM no se trata de velocidad de código, sino de velocidad de entrega de funcionalidades. Trabajas con objetos, no con cadenas.

✅ Por qué es genial:
— Unit of Work: Alchemy rastrea automáticamente los cambios en los objetos y los envía a la base de datos en un solo paquete transaccional.
— Seguridad: ¿Inyecciones SQL? Olvídate. Si no usas .text(), estás protegido por defecto.
— Migraciones: Sincronizar el esquema de la BD con tus modelos es magia que ahorra horas de rutina.
— Lógica de dominio: Ideal para sistemas complejos de comercio electrónico y paneles de administración, donde las relaciones entre tablas son más enredadas que la trama de "Interstellar".

❌ ¿Cuál es el truco?
— Overhead: El mapeo de objetos es una operación costosa. En conjuntos grandes (100k+ filas), notarás cómo el proceso de Python consume memoria y CPU.
— Problema N+1: El principal asesino del rendimiento. Un .joinedload() olvidado y tu servicio se cae bajo una lluvia de pequeñas consultas.

🪑 Silla nº2: SQL Puro / asyncpg (Elección para Highload)

Cuando te topas con el rendimiento, las capas intermedias empiezan a estorbar.

✅ Por qué es genial:
— Velocidad extrema: La diferencia de 2.5 veces no es broma. El protocolo binario de asyncpg permite exprimir al máximo el canal de red.
— Control total: Escribes exactamente el SQL que irá al planificador de la base de datos. Sin magia extra del ORM.
— Funciones específicas de la BD: Intenta usar eficientemente JSONB o índices específicos de Postgres a través de ORM; a veces se convierte en un trabajo de Sísifo.

❌ ¿Cuál es el truco?
— Tu responsabilidad: ¿Olvidaste escapar los parámetros? Felicidades, la base de datos está comprometida.
— Boilerplate: Tendrás que mapear manualmente las tuplas de la base de datos a modelos DTO/Pydantic. Es aburrido y genera errores.
— Mantenimiento: Leer 500 líneas de SQL crudo en el código después de seis meses no es placentero.


💡 Veredicto: El estándar de oro es el enfoque híbrido

No necesitas elegir solo uno. La arquitectura moderna se ve así:
1. SQLAlchemy ORM — para el 90% de las tareas: CRUD, lógica de negocio, migraciones y panel de administración.
2. SQLAlchemy Core — cuando los objetos ORM son demasiado pesados, pero aún no quieres escribir cadenas crudas.
3. SQL Puro (asyncpg) — para cuellos de botella: informes analíticos, inserciones masivas y microservicios con carga de 10k+ RPS.

Elige la silla según el tamaño de la carga ☝️

¿Y tú con qué escribes?
👨‍💻 Solo ORM, la vida es demasiado corta para escribir SQL a mano.
👨‍💻 Solo SQL Puro, no confío en esa magia.

#dos_sillas