For years, the dominant application architecture has followed a clear pattern: business logic lives in the backend, while the database is treated as a passive storage layer.
This approach works in simple scenarios, but in real-world systems —billing, third-party integrations, process automation, or systems with multiple entry points— it quickly introduces major issues: duplicated logic, inconsistencies, and increasing maintenance complexity.
The problem of distributed logic
When business logic is spread across multiple layers (APIs, scripts, services, integrations), structural problems emerge:
- Multiple versions of the same business rule
- Limited traceability and auditability
- Errors caused by inconsistent intermediate states
- Strong dependency on backend changes
In systems involving APIs, background jobs, and integrations, this becomes a critical issue.
A paradigm shift: the database as the core
In recent projects at Intercyd, we are applying a different approach: centralizing 80–90% of business logic directly in PostgreSQL.
This goes far beyond queries. It includes:
- Complex validations
- Data transformations
- Business rules
- Controlled inserts and updates
- State management
The result is a system where the database is no longer passive, but the true core of the architecture.
Advantages in real systems
Full consistency
A single source of truth ensures that all system entry points behave consistently.
Traceability and control
All operations are executed within the database, making them auditable and reproducible.
Simpler backend
The backend becomes an orchestration layer, focusing on communication rather than logic.
Reduced errors
By eliminating duplicated logic, inconsistencies are drastically reduced.
Beyond SQL: PostgreSQL as a platform
PostgreSQL is not limited to SQL. It supports additional languages inside the database:
- plpython3u for advanced logic
- plperl for specific processing
- Custom functions for complex workflows
This allows solving problems that go beyond standard SQL capabilities without leaving the database layer.
Reactive architectures with LISTEN/NOTIFY
PostgreSQL also enables lightweight reactive architectures.
Using LISTEN/NOTIFY, external workers can react to database events:
- Asynchronous processing
- Decoupled integrations
- Event-driven systems without heavy infrastructure
When this approach makes sense
This model is especially useful when:
- There are multiple system entry points
- Business logic is complex
- Full traceability is required
- External integrations are involved
Conclusion
PostgreSQL stops being just a storage system and becomes the core of the architecture.
This is not a technological change, but an architectural one: placing logic where it truly belongs.
And in many cases, that place is the database.