Database Choice, Lock-In, and the AI Rush with Peter Zaitsev
On why nobody owning Postgres became its advantage, the labels that sell you proprietary software, and what self-hosting costs once AI speeds up exploits.
Peter Zaitsev built Percona from a two-person company into one of the most respected open source database companies, and he co-wrote High Performance MySQL. He now advises open source startups as a board member, and he has watched engineering teams make the same database decisions for two decades.
We asked him how teams should choose a database in 2026, why Postgres keeps gaining ground, and where open source, security, and the AI rush change the calculation.
You can watch the full conversation below, or read the cleaned up transcript that follows.
This session was recorded offline as part of the Deep Engineering Interview Series. The transcript below has been lightly edited for clarity and readability.
Q. Tell us about yourself, your journey with Percona, and what you are focused on now.
I started working with databases more than 20 years ago, and I have been running Percona for 20 years. We help customers choose, deploy, and manage databases, and we focus on open source. We started with MySQL as a company, and we now cover the most popular open source databases.
Q. When you look at what engineering teams are reaching for in 2026, which databases come up most, and what is driving those choices at the technical level?
If you look at the databases most commonly used right now, I would name Postgres. It is by far the most popular database chosen by engineering teams these days, and that happens for both technical and a lot of non-technical reasons.
Q. Where do you see teams picking a database for reasons that do not survive contact with real load, and what should they weigh instead?
A lot of people choose a database based on what a friend is using, or something they read about at a conference. Relational databases are interesting. If you are building a basic application, you can do that in pretty much any database. You can choose MySQL, Postgres, Mongo, even Oracle, and you can build your application. Now if you are building something more special purpose, high performance, high volume, where you have to be very cost effective, then you have to think about the database a lot more.
Q. Stack Overflow’s developer surveys have placed PostgreSQL at the top for professional use for a couple of years now. From your years in the open source community, what do you think Postgres got right to earn that spot?
I think there are both technical and non-technical reasons behind Postgres, and the non-technical reasons are the most important here. PostgreSQL is truly a community database. Nobody owns Postgres, and that allowed everybody in the industry to cooperate on it. Amazon, Google, Microsoft, and a lot of others can all offer PostgreSQL as their own, so there is a level playing field for those companies. If you are promoting MySQL or Microsoft SQL Server instead, that is something owned by a particular company, and you are giving your competitor more power. That also helped PostgreSQL become ubiquitous. There is a PostgreSQL event happening probably every week somewhere in the world, because so many people are interested in promoting the technology.
From the technical standpoint, PostgreSQL is very good in terms of modularity and building extensions. If you think about what has been happening in the industry, time-series databases became important, and Postgres could very quickly provide an extension to do that. More recently AI arrived, and pgvector and vector search enabled building AI applications in Postgres very quickly. There are a number of other extensions in the same vein. That is a very important technical reason why Postgres is doing so well.
Q. Where is Postgres actually landing in production today, and which workloads are teams still wrong to put on it?
PostgreSQL has a lot of very big installations these days. You can find PostgreSQL ranging from general applications to a lot of use in the financial and banking sectors. It is again very ubiquitous, very scalable, a general purpose database.
Q. Data sovereignty and open source licensing are shaping deployment decisions right now. What technical constraints do they introduce, and where do they force an architecture change rather than just a policy one?
You touch on an important point, because a database is often chosen in the context of the platform. What we often see is customers making high-level decisions about where they go. They might say they are going to use AWS for everything, and that drives the database choice. Maybe they follow what the cloud suggests, and that is Postgres, but the proprietary version of Postgres that Amazon provides. It is important to look at what your organization needs in terms of data sovereignty and data independence, and what kind of controls you want over cost.
What I see here is a separation. A lot of startups say they just need to build as fast as possible, so they take the easy path, whether that is Amazon or Supabase. A lot of larger organizations have to think about cost and compliance. If they have a massive multinational operation, they have to follow local laws, and they decide they want more control. That often brings them to the open source side, running Postgres in a cloud native, Kubernetes-driven environment. That gives them a very high level of automation similar to what managed cloud vendors provide, while keeping them completely in control of their database.
Q. When a project relicenses or a vendor closes up, what does that actually cost the engineering team, and how do you design to keep that exposure low?
You are making an important point, because of what has happened in the last few years. People have even lost some trust in open source and started to understand that open source alone is not enough. You can see some companies, for example MongoDB, that had an open source database and then changed it, so now it is source available or entirely proprietary. There are also open source companies that shut down. And you can find open source software that still exists but is not maintained, which is not really safe to use in production.
So when you are choosing open source software, you first need to understand what open source actually is. A lot of companies right now are trying to trick you with words like open source compatible, which actually means enterprise software that is not open source but has some compatibility. Or they use a word like open core, which means there is a limited, crippled version that is open source, but what they actually want is for you to buy the proprietary, paid version. You need to understand what you are buying and whether open source is best for you.
The second reason, and this is why PostgreSQL is big, is having a large community, and a community of vendors too. If you choose an open source project you can hire many companies to help you. You can choose one vendor to give your business to, and if you do not like us, if we are too expensive or the service is not good, you can go somewhere else. With proprietary software you do not have that option. If you are running Amazon Aurora, only Amazon can really support that product. It comes down to deep experience.
In many cases early stage engineers are so focused on building their application and getting to market fast that they do not think about this. I am not sure all of them should. In a startup there are a lot more reasons to die than overpaying for your database. But as things transition to a more mature environment, those questions should be asked. A lot of enterprises started a painful migration away from Oracle a decade ago, spent many millions of dollars and many years, and are still on it, because databases are very sticky. If you have built a very complicated system locked in to certain database technologies, it may be hard to move.
Q. Let’s shift to security. Self-hosting an open source database puts the security burden on the team itself. What do you see teams underestimate, from patching cadence to backporting fixes into an older version they are stuck on?
Security is critical, especially now, because with AI, security holes can be found and exploited at a speed we have never seen before. If you take the responsibility on yourself, or you choose a vendor to do it for you, you need to make sure that policy is very strict. It is also very important to have a multi-layered security approach, because nothing gives you a 100% guarantee. You can see even some of the most serious environments get exploited. That means you need to make sure you not only have a defense and a process to prevent it, but also a plan for how you react when an incident happens.
This is a very specific area of experience for many teams. Even if they choose not to go with a fully managed cloud solution, it helps to work with someone on their security policies, and to have a contractual relationship with someone who helps with security patching. In many cases, when it comes to security, it becomes not just a technical question but a compliance question for a lot of larger organizations.
Q. Would you consider managed cloud databases in that scenario?
Managed cloud databases are not bad. They are a good choice for a lot of folks, and as I mentioned, they have a lot of trade-offs. When it comes to security, they do allow you to push more responsibility towards the vendor who manages your database. It is important to remember, when you think about the number of database choices deployed in the market, that there is no one-size-fits-all answer. It is not like saying you build an application, you need a database, so here are the steps, you choose this database, you run it this way on this operating system, you use this programming language. That is not helpful. There are a lot of considerations, and the answer varies.
Q. Teams are running document, vector, and graph databases alongside relational. Which of these are a dedicated store, and which are teams adding on hype rather than a real workload need?
It is a combination of technical and non-technical reasons. A lot of engineers like to explore and play with new technologies. They heard something at a conference or on a podcast that sounds very cool, and that is how a lot of technologies get introduced. In my experience, the more technologies you introduce, the more complexity you create. If you are a five-person company self-managing 10 databases, that is probably way too much complexity.
What I would suggest is starting with something, and PostgreSQL is often a good choice, then seeing how far you can take it. PostgreSQL can store relational data, it can store documents, and it can store vector data. Then maybe you find that in terms of scale, or some feature you need, you need a special purpose database, and you decide to use one for that given workload.
A lot of companies aspire to learn from giant-scale companies. They look at what Google or Facebook or OpenAI is doing and try to do the same. But those companies operate at a very different scale. For a lot of engineers, from a non-technical standpoint, it is just nice to do what the cool kids are doing.
Q. Vector databases specifically have exploded with the AI wave. Where does a purpose-built vector store beat adding vector search to Postgres or an existing engine?
Any database that is purpose-built for a particular task can often do better. It can have a more optimized store, and a language that is better suited for that task. That is quite common, and the same thing happened before with document-focused databases and time-series databases. What is very interesting with vector databases is that AI is moving so quickly. It really becomes a question of what exactly you need for building these AI applications.
We talk about a database storing vectors, and of course you may want to search them, but what else do you want the database to do? Maybe you want broader functions ranging from embedding generation, or some higher level functionality. Do we focus on the low level, which is vector storage, or do we want an application that can speak natural human language and bring all the intelligence that frontier models have, along with the enterprise and domain knowledge we already hold? Is that the database’s job, or is it a custom built application? A lot of that is still evolving, including how the architecture is going to look.
If you go to AI databases, my advice would be slightly different. Mature relational databases are many decades old. MySQL celebrated something like 30 years, and PostgreSQL is around the same. A lot of things in the core are already decided, and that is how we build them. The AI world is completely different, and every six months things change drastically. So when you are building AI applications, you really want to look at the dates. Best practices that are a year old are probably still very good advice for MySQL or Postgres in general, but for building AI apps they may be too outdated by that point.
Q. If you are advising a senior engineer building out data infrastructure this year, what is the decision you watch them get wrong, and what advice would you give them?
The advice would be to make sure you understand the needs you actually have. With AI this is quick now. Even if you write down what you think your real requirements are, you can ask AI what you are missing, and get some useful input to consider. In way too many cases the choice of database is a very quick decision without a lot of thought. As I mentioned, databases are very sticky, especially if you are building an application that will last for many years and run at large scale. So make sure to give it real thought.