PGDay Lowlands2026

We started Splendid Data in 2013, and the conviction was pretty simple: enterprises deserve better than being held hostage by proprietary database vendors. That was the founding idea, and honestly it still drives everything we do today. What we do is help organisations move from Oracle to PostgreSQL. And the way we do it matters to us.

We believe it should always be the customer's choice where they run PostgreSQL. Some go with our PostgresPURE distribution, others run on Azure, AWS or GCP. That is entirely fine with us. The goal is digital autonomy, not a new form of dependency with a different logo on it. Clients like UBS, Vodafone, BMW and KPN have made that journey with us.

Our alignment with the Postgres community I would almost call it philosophical. The community builds and shares freely because better software benefits everyone. We operate from exactly the same premise. When customers break free from vendor lock-in, the whole ecosystem wins. We are a commercial company, obviously. But our interests and the community's interests point in the same direction.

You have to put it in context. It is 2013, and Linux is becoming the de facto standard. Open source is finally breaking through across the full technology stack, not just at the edges. As database experts, we looked at that and said: if this is happening at the OS level, the database layer is next. And PostgreSQL was the obvious candidate.

At the same time we kept watching Oracle customers paying license and maintenance bills that made no sense whatsoever. They wanted out. But the path was too too risky to attempt without serious guidance and proper tooling. Nobody had built that yet. So we did. Cortex, our automated migration engine, came directly from solving the same problems repeatedly until we decided to automate the repetition away.

In hindsight it looks obvious. PostgreSQL had the technical foundation, the community momentum, and something Oracle never had: it actually wanted you to succeed without a licence and maintenance fees attached. In 2013 it felt like a calculated bet. Enterprise PostgreSQL was not yet the default conversation it is today. We believed it would be. And here we are. I genuinely cannot imagine building this business around anything else.

Look, if I am honest about what drives us, it comes down to one thing: making migrations succeed that other people said were too complex. That sounds straightforward. It really is not. Oracle environments at enterprise scale are messy. Years of accumulated logic, proprietary functions, package structures nobody fully understands anymore, and at least one stored procedure that everyone is afraid to touch because the person who wrote it left in 2009. We have all seen it.

Our philosophy is simple: complexity is not an excuse. That’s our job. We built Cortex to automate up to 90% of the process, and we put experienced engineers on the parts that still need human judgment. What we don’t do is migration theatre. You know the type: a beautiful report lands on your desk and then six months later the project has quietly stalled, and nobody wants to talk about it.

Underneath all of that sits a deeper belief. Vendor independence isn’t just financially smart. It is strategically important. And is becoming a legal requirement. Regulated industries across Europe are asked to demonstrate they can exit a technology provider if they need to. We have built exactly the tools that make that possible.

Without a doubt: orafce. If you’re in the process of migrating Oracle workloads to PostgreSQL, orafce is our hero, bridging the gap between the two worlds. It provides Oracle-compatible features within PostgreSQL, which means that large portions of the code can run without modifications from day one.

This is no small matter. In a typical Oracle migration, many of the problems arise from Oracle-specific built-in functions that do not exist in PostgreSQL. orafce significantly reduces this problem. It doesn’t solve everything, that’s what Cortex is for, but it considerably reduces the amount of code that needs to be rewritten.

Another thing I really appreciate about orafce is that it’s truly a collaborative effort by the community. The people contributing to orafce have a deep understanding of the challenges of Oracle migration, and that’s evident in the way the project is evolving. For us, it’s both a technical tool and a reminder that the PostgreSQL ecosystem builds exactly what it needs, when it is needed, without waiting for a vendor’s roadmap.

My three words are strict, generous and stubborn.

Strict, because the bar for what makes it into PostgreSQL is high. There’s no marketing department pushing features through just to meet quarterly targets. Every patch gets scrutinised, debated, improved. Sometimes to a degree that tests your patience, I will be honest. But the result is software you can actually trust in production. That is the trade off and it is absolutely worth it.

Generous, related to the amount of knowledge people freely share, at conferences, on mailing lists, in documentation, is honestly remarkable. These are people who could charge serious consultancy rates for what they know. They just give it away, because they genuinely believe the ecosystem is stronger for it.

Stubborn, in the best possible sense of the word. The community doesn’t chase trends. It doesn’t change course just because a venture-capital-backed competitor has announced something slightly eye-catching. It continues to develop excellent software on its own terms, at its own pace and according to its own standards. In a technology landscape that is full of noise, that kind of stubbornness is becoming rare but it’s increasingly valuable.

Everything I am about to recommend lives in our Knowledge Center on splendiddata.com. We have put serious work into making it a real resource, not a lead generation trap dressed up as content.

There is quite a lot there. Technical deep-dives on migrating from Oracle to PostgreSQL, background material on PostgresPURE, and a growing library of blogs covering everything from migration architecture to honest comparisons with other tools in the market. We do not shy away from those comparisons. If something else solves your problem better, you should know that.

What I like about the Knowledge Center is that it works on two levels. If you are an engineer who wants to understand how automated PL/SQL conversion works under the hood, it is there. If you are a CTO trying to build a business case for leaving Oracle, the whitepapers and framing are there for you too. So, just have a look!

Yes, we have PostgresPURE. The idea came from something we kept hearing from enterprise customers including those in the public sector. They would look at us and say: okay, we technically trust PostgreSQL, but how do we run this to meet the requirements of our auditors and board?

That is a fair question. PostgreSQL is absolutely production-ready. Nobody serious disputes that anymore. But most large organisations are not yet set up to run it the way they run a vendor product with a support contract, a certified build, and someone to call at two in the morning.

PostgresPURE is our answer to that. It offers security hardening, long-term support commitments and certified builds, as well as the operational tooling around it. What I am particularly proud of is what we didn’t do. We did not fork PostgreSQL. We did not introduce proprietary extensions that quietly recreate the lock-in people just escaped from Oracle. It is everything that sits between great open-source software and an environment that a regulated financial institution can actually put into production with confidence.