A few months ago, I was in a meeting with a colleague, the CTO of a large company. It was not a demo or a sales pitch. It was more of a relaxed conversation between technical professionals. While there, a topic arose that I cannot get out of my head:
“Every time we need to move data from Oracle to BigQuery, it is a Project (with a capital P). With its own budget, team, and timeline. Between 35,000 and 70,000 euros. And when it is from SAP, it is even worse.”
He leaned back in his chair.
“Do you know what we do? We use another data platform as a staging platform. We extract the data from one site, leave it in another, and from there we push it to the next.”
An intermediate platform. Just to move data from A to B.
I kept thinking about the idea that he was not describing a technical problem; he was describing a tax. A toll that his company paid every time it needed its own data to be where it was required. Multiplied by dozens of integrations per year.
I must say he did not speak with indignation, but rather with resignation. Truthfully, it troubled me that he expressed it as if it were inevitable. It was undoubtedly a reflection of what we are experiencing in the sector.
When I left that meeting, I thought about something we had already been seeing at QRY. We already connect with Oracle, SAP HANA, BigQuery, Snowflake, PostgreSQL, Redshift… We have native connections with multiple platforms, so that was no longer the challenge. Added to the above, we had something that no traditional integration tool has: an artificial intelligence engine that understands data structure, can generate SQL, Python, or whatever is necessary, and can correct itself when something fails.
The question was almost obvious, and yet no one was asking it: if we already know how to read from any source and write to any destination, why do we continue to treat every data movement as an engineering project?
There is no need to invent a new ETL, but there is a need to change the question. Stop thinking of pipelines as infrastructure and start thinking of them as conversations: “take this data from here, transform it like this, and leave it there.”
But moving data is only half the problem. The other half is trusting what arrives. How many times does a pipeline move thousands of records and no one realizes that half come with null values, broken formats, or keys that no longer exist at the destination? Ah, my friend! The data arrives, yes, but it arrives wrong, and someone discovers it weeks later when a report does not add up or a model returns absurd results.
I kept thinking about how we did it, almost out of pure professional obsession, and I said to myself: From the beginning, we designed validations as part of the flow, not as something added later.
Business rules are executed within the pipeline, and if a critical field arrives empty, the record is discarded. If a metric deviates from the expected range, the pipeline stops before contaminating the destination. And finally, if something fails, the artificial intelligence proposes a correction before anyone opens a ticket.
So? If we were already doing this (the integration of QRY Forge within QRY does exactly this), why is the same frustration being repeated in different companies of various sizes and sectors?
My thoughts return to the meeting with my colleague, and the pattern is always the same: data trapped in silos, saturated engineering teams doing plumbing instead of generating value, and a hidden cost that no one adds up but everyone pays. That €50,000 project that is repeated five, ten, twenty times a year. That month and a half of waiting for something that is conceptually simple.
Sometimes I am asked what the competitive advantage of integrating artificial intelligence into a data platform is. My answer is not “it generates SQL faster”; it is that it eliminates repetitive tasks that do not generate value, reduces times, and allows human teams to focus on strategy and innovation.
That conversation taught me something I already knew but had not articulated: the most expensive problem in data is not the one you do not know how to solve, but the one you solve over and over again.
Sergio Rodríguez de Guzmán, CTO Puedata
