Durante años, la arquitectura dominante en el desarrollo de aplicaciones ha seguido un patrón claro: el backend contiene la lógica de negocio y la base de datos actúa como un simple sistema de almacenamiento.
Este enfoque es válido en escenarios sencillos, pero en entornos reales —facturación, integraciones con terceros, automatización de procesos o sistemas con múltiples puntos de entrada— empieza a generar problemas importantes: duplicidad de lógica, inconsistencias entre sistemas y una complejidad creciente difícil de mantener.
El problema de repartir la lógica
Cuando la lógica de negocio se distribuye entre diferentes capas (APIs, scripts, servicios, integraciones), aparecen problemas estructurales:
- Diferentes versiones de la misma regla de negocio
- Dificultad para auditar qué ha ocurrido y por qué
- Errores derivados de estados intermedios inconsistentes
- Mayor dependencia del backend para cualquier cambio
En sistemas donde intervienen múltiples procesos —APIs, jobs, integraciones externas— esto se convierte en un problema crítico.
Un cambio de paradigma: la base de datos como núcleo
En los últimos años, en Intercyd estamos aplicando un enfoque distinto: centralizar entre el 80% y el 90% de la lógica de negocio directamente en PostgreSQL.
No hablamos solo de consultas, sino de lógica real:
- Validaciones complejas
- Transformaciones de datos
- Reglas de negocio
- Inserciones y actualizaciones controladas
- Gestión de estados
El resultado es un sistema donde la base de datos no es un componente pasivo, sino el núcleo real del sistema.
Ventajas en sistemas reales
Consistencia total
Existe un único punto de verdad. No importa desde dónde se acceda al sistema (API, importación, integración), la lógica siempre es la misma.
Trazabilidad y control
Todo ocurre dentro de la base de datos. Cada operación puede ser registrada, auditada y reproducida.
Simplificación del backend
El backend deja de ser un lugar donde vive la lógica y pasa a ser una capa de orquestación: recibe datos, llama a funciones y devuelve resultados.
Reducción de errores
Al eliminar duplicidades y centralizar reglas, se reducen significativamente los errores derivados de inconsistencias.
Más allá de SQL: PostgreSQL como plataforma
Uno de los aspectos más potentes de PostgreSQL es que no se limita a SQL. Permite integrar otros lenguajes dentro de la propia base de datos:
- plpython3u para lógica avanzada
- plperl para procesamiento específico
- Funciones personalizadas para integraciones complejas
Esto permite resolver problemas donde SQL por sí solo se queda corto, sin salir del entorno de la base de datos.
Arquitecturas reactivas con LISTEN/NOTIFY
Otro punto clave es la capacidad de construir sistemas reactivos sin necesidad de infraestructuras complejas.
Mediante LISTEN/NOTIFY se pueden activar procesos externos (workers) que reaccionan a eventos de la base de datos:
- Procesamiento asíncrono
- Integraciones desacopladas
- Sistemas event-driven ligeros
Esto permite construir arquitecturas robustas sin necesidad de colas externas o sistemas adicionales.
Cuándo tiene sentido este enfoque
No todos los proyectos necesitan este modelo. Pero es especialmente útil cuando:
- Existen múltiples puntos de entrada al sistema
- La lógica de negocio es compleja
- Se requiere trazabilidad completa
- Hay integraciones con terceros
Conclusión
PostgreSQL deja de ser un sistema de almacenamiento para convertirse en el núcleo del sistema.
El cambio no es tecnológico, es arquitectónico: diseñar sistemas donde la lógica vive en el lugar correcto.
Y en muchos casos, ese lugar es la base de datos.