During a recent infrastructure migration from the US to Europe, I discovered something uncomfortable.
Companies were looking at their data every day.
Through dashboards.
Through automations.
Through internal tools.
It all looked consistent.
But it was not.
Most of them were using n8n,Make, NocoDB, and a PostgreSQL database. At first it looked like everything was connected. Relations appeared to be defined.
The data seemed to be structured.
But when looking at NocoDB (tool to manage databases) it was showing a representation of relationships, not the real model as it truly existed in PostgreSQL. This is ok when you only need to use that data to create reports or something else made by human analysts but is not ok when you want to use the data for another purpose. When I needed to remove dependencies and stop relying on the interface layer, the abstraction collapsed.
What did I find?
Virtual relations not enforced at database level
Logic embedded in automations instead of schema
Queries written around what the ui exposed, not what the data actually was in the database
Data that was only accessible through the interface layer, not directly from the database
In the end, the system was not the database. The system was the interface.
It had structure in appearance. Not in architecture.
This is more important than it sounds.
Because many companies believe they own their systems when what they really own is a stack of tools connected by convenience.
If removing one tool breaks your business logic, you don't control your system.
You are renting coherence.
Migration exposes this.
Tool replacement exposes this.
Moving servers from the US to Europe is easy. Reclaiming architectural clarity is not.
In music production, noise is not the enemy. Unstructured noise is.
In software, abstractions are not the problem. Unexamined abstractions are.
A system should survive the removal of its interface. If it doesn't, the interface was the system.
And that is a risk.
More articles on my website www.agarban.com
Top comments (0)