Around midday on the first day of Open Source Summit Europe 2026 in Prague, I stopped at the Percona booth, which had one of the best views over the city, for a Udienza conversation with Alastair Turner, who works on Percona’s community side.
It started with his t-shirt, a hand-drawn “Unlocking Databases” design that, as he pointed out, predates the AI era. It ended with one of the clearest arguments I have heard for keeping AI data in the databases you already run. Quotes are from our recording, lightly edited for clarity.
Twenty years of Percona
“Percona was born just over 20 years ago; we had our 20th birthday this year, around performance problems with MySQL. We began building tools for MySQL, for monitoring and management, for backup, and a few years later expanded into doing that for MongoDB as well.”
The model is simple: build on the community editions of MySQL and MongoDB, and later PostgreSQL, make them more enterprise-friendly, and keep it all open source. “You can go and get it and run it if you like. And when you decide you want some support, you can come and talk to us.”
Percona was also one of the companies, alongside AWS, Google, Ericsson and others, involved in forking Redis into Valkey after Redis changed its licence. Valkey was a Diamond sponsor at the summit.
More forks are coming
My question about the future got a sober answer:
“I think we’re going to see another wave of these forks and licence changes. The pressure on VC-funded companies is on. A lot of people are under greater threat of running out of money, so I think we’re going to see some strange behaviours around people trying to pull some more money in.”
That fits the whole week in Prague. The neutral governance conversations, OpenSearch, OpenBao, Valkey: all of them exist because a single vendor changed the rules. If your stack depends on single-vendor open source, plan for it.
The relational database is not going away
“People have been telling me for 20 years: why are we learning about relational databases, they’re disappearing, it’s a dinosaur technology. These projects aren’t going to go away.”
He mentioned that the community had just celebrated the 30th anniversary of open source Postgres at a conference in Vancouver.
Vectors belong where your data already is
This was the part I found most useful for AI platform work. Specialist graph and vector databases keep appearing, but, in his words:
“A lot of it keeps coming back to the big relational engines, because that’s where all the operational capabilities are: crash safety, backup, failover. You don’t need the world’s best vector database for most vector applications. Vector capabilities in Postgres, in Mongo, in MySQL are enough for you.”
He expects the same pattern for whatever comes next in AI: a few specialist systems for niche cases, and mainstream relational databases absorbing the capability for everyone else.
When I said that people tend to think of AI as chatbots and agents, and forget the data underneath, he agreed and widened it:
“There’s a lot of focus for things like chatbots on text data and embeddings. But a lot of what people want to know is numbers. We still need to add up the numbers and let people explore them. And we don’t want to be putting the embedding data somewhere else. Keep it where the numbers are, where the inventory information is. Keep them all together.”
Sovereignty makes this argument stronger
I asked whether sovereignty changes the picture. His answer connected architecture to the sovereignty theme of the week:
“Sovereignty amplifies the question of architectural complexity, because it makes operational complexity a bigger deal. You no longer have one big relational database, one big graph database and one big vector database. You have to replicate these things in the various territories you operate in. And that pushes further towards using the exotic capabilities in mainstream databases, rather than deploying exotic technologies.”
That is the strongest practical case I have heard for pgvector over a separate vector store: every extra system multiplies by the number of regions you must keep data in.
Where to find them
Alastair’s work is getting people to build with Percona on its open source software, and the hub for that is percona.community. It hosts the tools Percona builds on top of the MySQL and MongoDB community editions, and PostgreSQL add-ons such as transparent data encryption and OIDC support, with forums and links to the GitHub projects.
My takeaways
- Default to the database you already operate. Add vector search to Postgres or MySQL before adding a new system, especially if you run in several regions.
- Watch the licence of your data layer. Forks happen when funding pressure meets popular open source. Prefer projects under neutral governance.
- Do not forget the numbers. AI applications still need transactional data, reporting and backups. Keep embeddings next to the data they describe.
For a comparison of the dedicated options, see my guide to vector databases on Kubernetes. Thanks, Alastair. The full episode will be on udienza.com.
