Deep Engineering #56: Peter Zaitsev on Choosing a Database Like You Can Never Leave It
Database choice is the decision teams rush most and regret longest, because a database is far easier to adopt than it is to leave.
Capacitor - Shared memory for your team’s coding agents. Searchable. Shareable. Vendor-neutral. Scored.
Capacitor records the session behind the work: what agents tried, what teammates rejected, what finally passed, and why it mattered. This gives you vendor-neutrality to move across multiple coding agents, multiplayer - collaboration on coding sessions, faster PR reviews, evals on code & more.
✍️ From the editor’s desk,
Welcome to the 56th issue of Deep Engineering!
The PostgreSQL Global Development Group shipped the second beta of PostgreSQL 19 on July 16, only a few months after version 18 reached general availability and began landing in production systems. A community project that already tops every major developer survey keeps compounding its lead one disciplined release at a time. Postgres has effectively become the default database, and most teams now reach for it without pausing to ask whether it fits the problem in front of them.
That ease is exactly where the trouble starts, because a decision everyone treats as obvious is a decision nobody examines. Moving off a database once an application leans on it can take years and burn through real budget, and the forces that make the choice consequential have only sharpened this year. Relicensing moves keep redefining what the words open source actually protect, and by Google’s own threat-intelligence reporting attackers now weaponize many newly disclosed flaws before a patch is even available, which turns the question of where and how you run your database into a live operational risk rather than a matter of preference.
That is exactly the terrain Peter Zaitsev has worked his whole career, an entrepreneur, author, and co-founder of Percona. Two decades of helping companies choose, run, and sometimes escape their databases give him a sharp read on which reasons hold up under real load and which ones fall apart the moment the system starts to matter.
In today’s issue, he makes the case for treating that choice with the seriousness it earns, and for choosing as though you can never walk it back.
You can also watch our full conversation with Peter Zaitsev here.
Let’s get started.
Building Intelligent AI Agents with GraphRAG
This Agentic Engineering live bootcamp walks you through building an agent that investigates across a knowledge graph, remembers what it found, and returns answers you can put in front of a user.
Friday 31 July to Saturday 1 August, online.
Register with code DEEPENG40
Expert Insight
Databases are sticky. Most teams underestimate the commitment
by Saqib Jan with Peter Zaitsev
Most teams choose a database the way they choose a lunch spot, quickly and on somebody else’s recommendation. A friend runs it in production, a conference talk made it sound fast, or the cloud console offered it as the first option on the list. The 2025 Stack Overflow Developer Survey put PostgreSQL at the top for the third year running, in use by 55.6 percent of all developers and 58.2 percent of professional ones, far ahead of second-place MySQL. The default has never been clearer. But the decision behind it still rarely gets the weight it deserves.
Peter Zaitsev has advised companies through twenty years of these choices, from the greenfield pick to the migration nobody wanted. He co-founded Percona, grew it from a two-person company into one of the most respected open source database companies in the industry. His view of what most teams get wrong is straightforward. “Databases are very, very sticky,” he says. Once an application leans on one, unwinding that dependency can take years and burn through budgets, which is exactly why choosing one casually is the expensive mistake.
The cost is not hypothetical. Sharing from his experience advising enterprises through these migrations, Zaitsev says, “They started this kind of very painful migration away from Oracle a decade ago, and many, many millions of dollars, many, many years, they’re still on it.” A database that took a weekend to adopt can take a decade to leave. That asymmetry is the reason the rest of his advice matters.
Nobody owns Postgres, and that is most of why it won
In our conversation, I asked Zaitsev why Postgres reached the top, and his answer began with the part engineers tend to skip. “PostgreSQL is truly a community database. Nobody owns Postgres,” he says, and as he sees it that governance fact, more than any feature, explains the dominance. Because no single vendor controls it, every cloud can offer it as a first-class product without handing a rival an advantage. “Amazon, Google, Microsoft, a lot of others, they can offer PostgreSQL as their own,” he points out, where promoting MySQL or SQL Server means promoting something a competitor owns.
The technical case follows the same shape. Postgres extends rather than forces migrations, so each new demand becomes an extension instead of a second database. Time-series work got its extension, and the AI wave got pgvector, the open source extension that adds vector types and similarity indexes and now ships enabled on managed Postgres from AWS RDS to Supabase. “pgvector, vector search, enabling building AI application in Postgres, that came about very quickly,” Zaitsev tells us. The base keeps getting stronger underneath all of it, and the September 2025 release of PostgreSQL 18 added a new asynchronous I/O subsystem the project measured at up to three times faster on reads.
Open source is not enough
The reason to prefer the community model becomes obvious the moment a vendor changes the rules. “People even kind of lost trust in open source and started to understand that open source is not enough,” Zaitsev reflects, and he points straight at the pattern that taught them. MongoDB moved to the Server Side Public License in 2018, Elastic followed in 2021, HashiCorp adopted the Business Source License in 2023, and Redis switched to source-available terms in 2024 before adding an open license back in 2025 under community pressure. Each move left production users holding a version they could no longer upgrade under the terms they signed up for.
Zaitsev’s warning is that the marketing hides the trap. “A lot of companies right now are trying to trick you, using words like open source compatible,” he cautions, which usually means proprietary software wearing a thin layer of compatibility. Open core is the other tell. “There is some sort of limited, crippled version which is open source, but what they actually want is for you to buy the proprietary version,” he says. The protection he trusts is not a license badge but a market. A real open source project has many vendors, so a team unhappy with one can leave, and run a closed product like Amazon Aurora and only Amazon can support it, which puts the depth of experience and the leverage on one side of the table.
Self-hosting now means racing the exploit clock
Self-hosting an open source database moves the security burden onto the team, and the clock on that burden has changed. Zaitsev warns that with AI, security holes can now be found and exploited “at the speed which was never seen before,” and the incident data agrees with that. Google’s M-Trends 2026 report estimated the mean time to exploit a newly disclosed vulnerability at roughly negative seven days, meaning many flaws are weaponized before a patch exists, and Google’s threat intelligence group has reported the first zero-day it attributes to an AI-developed exploit.
That pace changes what good looks like. Zaitsev argues for a layered posture and an honest plan for failure, because prevention alone never reaches certainty. “Nothing gives you a 100 percent guarantee,” he reminds us, so the real question becomes how fast a team detects and responds, not only how well it defends. For many teams the practical answer is a contract, and even those that avoid a fully managed service should have someone on the hook for patching. In regulated environments the whole subject stops being a technical choice and becomes a compliance one, which is where managed databases earn their place by letting a team push responsibility to the vendor who runs the system.
Doing what the cool kids do is not a workload
The pull toward document, vector, and graph stores is often social before it is technical. “A lot of engineers, they like to explore and play with new technologies,” Zaitsev says, usually after hearing about them at a conference or on a podcast. He does not moralize about curiosity, but he counts the cost. “The more technologies you introduce, the more complexity you create,” he says, and a small team running many engines pays that bill every day. “If you are a five-person company and you are self-managing 10 databases, there’s probably way too much complexity.”
His rule is to start narrow and let real limits, not fashion, force the next move. Postgres holds relational data, documents, and vectors well enough that most teams travel a long way before they need anything else, and only a genuine ceiling on scale or a missing feature should justify a dedicated store. Purpose-built systems do win when the workload is real, because a database built for one task carries a more optimized store and a better language for it. The catch with AI is speed. “The AI world is completely different. Every six months things drastically change,” Zaitsev reasons, so a team building AI features has to check the date on its advice, since guidance a year old still serves Postgres or MySQL fine and can already be stale for anything touching models.
Choose like you cannot leave
The through-line of Zaitsev’s advice is to match the seriousness of the decision to the difficulty of reversing it. He wants teams to write down their actual requirements rather than inherit a default, and he is happy to use the newest tool to pressure-test the old discipline. “You can actually ask AI, hey, what am I missing,” he says, treating a model as a fast second reader on a requirements list. The point is not the tool. It is that a choice this durable deserves more than an afternoon.
That is the gap he keeps returning to. Teams decide in a hurry and then live with the result for years, on infrastructure that only grows harder to change as the application matures on top of it. Postgres has made the safe default easy, and the survey numbers show most teams taking it. The harder work starts after the default, in the licensing terms, the security posture, and an honest reading of what the workload actually needs.
In case you missed
Database Choice, Lock-In, and the AI Rush with Peter Zaitsev
Peter Zaitsev built Percona from a two-person company into one of the most respected open source database companies in the business, 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 data…
Industry Perspective
Codex as a Teammate, Not Autocomplete
Chuck McCullough on running a reliable engineering workflow with OpenAI Codex, scoping work into slices, testing first, and reviewing for whether it fits.
🛠️ Tool of the Week
CloudNativePG, the Kubernetes operator for running production Postgres on infrastructure you control
CloudNativePG runs Postgres as a native Kubernetes workload and handles failover, backups, and rolling upgrades the way a managed service would, while the data and the control plane stay inside your own cluster.
New DatabaseRole resources manage Postgres roles as declarative GitOps objects with password-free certificate authentication.
A Kubernetes Lease now gates primary promotion, so replicas fail over without waiting out the full timeout.
In-place major upgrades run pg_upgrade against mounted extension images, cutting version-migration downtime.
Operator and Postgres images ship signed with SBOM and provenance attestations for supply-chain verification.
📎 Tech Briefs
PostgreSQL 19 Beta 2 adds native SQL/PGQ property-graph queries - Postgres 19 exposes relational tables as property graphs via GRAPH_TABLE pattern matching, so fixed-depth traversals no longer need a graph database.
CISA adds an actively exploited SharePoint Server RCE to its Known Exploited Vulnerabilities catalog - CISA confirmed active exploitation of CVE-2026-58644, a deserialization remote-code-execution flaw in on-premises SharePoint Server, and ordered urgent patching.
MariaDB Community Server 10.6 reaches end of life - MariaDB’s last old-model LTS no longer receives bug or security fixes, so 10.6 shops now face an unavoidable migration.
Autobase 2.9.0 released. The open source automated Postgres high-availability platform now manages cluster infrastructure after deployment, not only initial setup.
CISA flags an actively exploited authorization bypass in Langflow - CISA confirmed in-the-wild exploitation of CVE-2026-55255, an authorization bypass in the open source LLM app builder Langflow.
📣 Contribute to Deep Engineering
Pitch a practical deep dive under your byline. Or if you lead a team, we would like to interview you and build an engineering leadership feature around your story.
Subscribe to Deep Engineering newsletter and message us through the chat option, or email us at saqibj @ packt.com.
That’s all for today. Thank you for reading this issue of Deep Engineering.
We’ll be back next week with more expert-led content.
Keep building,
Saqib Jan
Editor-in-Chief, Deep Engineering
If your company wants to reach senior developers, software engineers, and technical decision-makers, speak to us about partnering with Deep Engineering.
 | A guest post by
|