AI-Generated Pull Requests Are Crashing Postgres Instances Daily, And the Only Way Through Is Architectural

AI-assisted development is generating pull requests faster than most Postgres instances can absorb them. Engineering teams shipping AI features are capturing massive new telemetry streams, and the volume of data hitting the backend is exploding. The last mile of AI transformation keeps stalling at the same place: the operational and infrastructure layers underneath, where the pace of deployment collides with data governance requirements and database architectures that were never designed for this velocity.

The Read Replica sat down with Amanbolat Balabekov, Balabekov, Staff Engineer at Wolt, a DoorDash company. With over a decade of full software lifecycle experience, he has led zero-downtime migrations of legacy Python and Ruby monoliths into Go-based microservices at companies like Delivery Hero and Sphere Partners. Having managed engineering teams of up to 30 people, he brings a battle-tested perspective on which database patterns survive in production and which buckle under pressure.

For Balabekov, the sheer speed of modern, AI-assisted development has become a primary pressure point for database stability. "With the amount of development happening right now and the number of pull requests developers are pushing, anyone can easily kill a single instance of PostgreSQL on a daily basis," he said. "You either create guardrails to make sure that doesn't happen, but then you are stopping development, or you find a balance. You want to enable developers to push features quickly, but you don't want to spend excessive time and money looking after your infrastructure."

It's the same velocity problem that engineering leaders at companies like Snap are confronting from the code review side: when AI collapses the time between idea and pull request, the systems downstream, databases, pipelines, and infrastructure, absorb the impact.

The architecture question that determines resilience

Managing the risk of runaway queries starts with drawing hard boundaries. A bad query's impact depends entirely on the underlying architecture.

"Just for the Postgres database itself, it is an operational database," Balabekov said. "So do you have a single database per service, or do you have a single database for your whole company? That is the first question. The second question is whether we keep all the data inside the operational database or move it out to a data lake. You want to keep the operational database as small as possible because scaling Postgres beyond a certain degree becomes difficult, especially when joining multi-region data."

Throwing bigger hardware at the problem only buys a team time. Because Postgres traditionally leans on vertical scaling, pushing a single system to its limits often reveals a predictable pattern. The tradeoff between scaling up compute versus distributing reads is one that every growing team eventually hits. At a certain point, adding more compute becomes a budgeting problem rather than a technical one.

"You can have just a couple of gigabytes of data, but a wrong query or function can kill your instance," Balabekov said. "You can scale vertically, but eventually, the limit becomes your budget. You can automate that scaling up to a point, but once you hit that ceiling, what are you going to do?"

It's a constraint that practitioners across the industry keep rediscovering. Teams building AI-ready systems on Postgres find that readiness starts with the query patterns nobody bothered to optimize, and a single unoptimized query under agent-driven load can degrade a system that performed perfectly under human-driven workloads.

When vertical scaling hits the budget wall

Reaching that financial ceiling is often the exact trigger for teams to graduate toward horizontal sharding and regional routing. While the industry continues experimenting with horizontal scaling concepts for Postgres, stretching one operational database across continents adds overhead and new points of failure. OpenAI offered one reference point when it disclosed that ChatGPT's workload runs on a single-primary Postgres instance with nearly 50 read replicas, but that architecture serves a single-region write path, not a globally distributed one. At global scale, practitioners like Balabekov favor strict architectural isolation.

"With truly multi-regional sharding, you might have one shard in Korea and another in New York, paired with a routing layer that directs users to their local instance," he said. "This achieves three things. First, it reduces latency. Second, it keeps the regional database as small as possible, allowing you to tightly control the CPU, RAM, and disk allocation. And third, it solves the data governance problem if implemented correctly."

When operations span several regions, keeping those environments isolated is a matter of control versus convenience. Fully managed multi-region features from cloud providers look attractive on paper, but relying heavily on those abstractions can leave a team flying blind during an incident.

Governance by design, not by accident

A 2026 industry survey on database change governance found that only 28.1% of organizations have standardized, consistently enforced controls at the data layer. For Balabekov, closing that gap starts at the schema.

"From the beginning, when you're writing the schema for your database, you have to tag those columns. For every field, you must explicitly define what is and isn't PII," Balabekov said. "That means your web application understands the data classification from the start. By the time it reaches the database, the system knows whether to encrypt it. When you eventually send that data downstream to Kafka, you guarantee that it is masked or encrypted from end to end, rather than just pushing raw data and hoping someone deals with it later."

The principle maps to what security engineers at companies like Webflow are discovering as AI agents expand database exposure across the organization: when access controls aren't enforced at the data layer, the risk of a single misconfiguration grows proportionally with every new agent or tool that touches production data.

Isolating the AI playground from production

Democratizing data access across an organization safely demands clear architectural discipline. By enforcing Command Query Responsibility Segregation and isolating operational writes from analytical reads, teams can introduce AI tooling without jeopardizing the primary database. "You must maintain a strict separation between your writes and reads to make sure analytical queries don't break your operational database. By using time-series extensions on a read replica, you can safely query the data however you want. The real value is that you no longer need a dedicated data analyst to write those queries. Product teams can use an AI layer to pull the data they need instantly, and the analytics team simply verifies the output."

The read-only pattern Balabekov describes is the same architectural boundary that infrastructure leaders at other enterprises have landed on as the only AI guardrail that consistently holds: an agent that can read everything but write nothing doesn't leave anything to negotiate.

In setups like this, Postgres acts as the core operational store, while extensions and replicas provide a safe playground for AI-assisted exploration. Some engineering leaders find that this abstraction flattens traditional organizational silos. By querying database schemas via natural language, product teams can pressure-test ideas earlier, sidestepping formal documents and long feedback loops.

"In the past, you would have a product manager writing the PRD first, passing it to the engineering manager, and going through a constant feedback loop," Balabekov said. "Now, I see real-world examples where product teams use AI to create a working demo in a couple of hours. Instead of writing a PRD, they just pass that demo to the developers. The engineering focus then shifts to making sure the product actually works, is scalable, and doesn't have bugs. You still need software engineers, but their time is spent making sure the product scales."

Every engineering leader shipping AI features in 2026 is learning the same lesson: AI compresses the distance between idea and prototype, but the gap between prototype and production-grade system is where engineering discipline either holds or breaks.

Postgres as the operational backbone

These patterns reinforce each other. Regional sharding limits blast radius, physical isolation keeps governance enforceable, schema-level PII tagging catches sensitive data before it leaks downstream, and AI-enabled querying on read replicas gives product teams access without putting the operational database at risk. Together, they form the playbook for teams trying to get AI projects past the prototype stage and into production without rebuilding their entire data layer.

Despite its limitations at massive global scale, Postgres keeps earning its place as the starting point. For teams that haven't yet hit multi-region complexity, the ecosystem offers more runway than most alternatives.

"You can use Postgres as a small data lake, a serving layer, or really for everything. With features like JSON indexing and storing Protobufs as binary data, it is incredibly versatile," Balabekov said. "You can even utilize the Write-Ahead Log to read data as a replica before streaming it to Kafka. It remains a very strong choice for early scaling. AI is fantastic for solving the biggest pain point of querying and data discovery, but when it comes to the underlying infrastructure, everything else is just pure operational engineering."