AI Readiness Starts With the Queries Nobody Bothered to Optimize

Somewhere inside every large enterprise, there's an SQL Server instance running reporting queries that take minutes when they should take seconds, a Postgres deployment scanning full tables because nobody set up partitioning, or an Oracle database executing joins written by a contractor who left three years ago. These systems power production workloads for millions of users, and they work well enough that nobody's looked under the hood in years.

Then an AI initiative lands on top. "Data readiness" has become the default postmortem for stalled initiatives, but for many organizations running complex, multi-engine database environments, the story is often more mundane. The existing systems could have handled the workload if someone had re-tuned them first.

Fawad Khan is a Database Administrator at Health Care Service Corporation, one of the largest customer-owned health insurers in the United States. He specializes in Azure SQL and manages upstream database environments that feed analytics and emerging AI workloads, and writes his own SQL packages and code samples for HCSC's 27 million users. When a query is slow or a new workload is choking on a schema designed for something else, he's one of the people who gets the call.

Staying inside the stack

Khan works across Oracle, Teradata, DB2, Postgres, and SQL Server simultaneously. As with most large legacy orgs, each part of the stack was inherited from a different era, maintained by a different team, running for reasons that are part technical and part institutional memory. It's messy, but it's normal. Most enterprises at this scale are running some version of the same sprawl.

"Teams either underuse what they've bought or overbuy what they don't need, and both lead to the same inefficiency," Khan told The Read Replica in a recent interview. A recent Gartner survey of 782 I&O leaders found that only 28% of AI use cases in infrastructure fully meet ROI expectations, and that the ROI gap isn't driven by model sophistication — it's driven by how well the technology is integrated with what's already running. Khan's team's default is to evaluate current platforms and core capabilities first, optimize what's in-house, and add new software only when existing systems genuinely can't do the job, keeping teams focused on actual data bottlenecks rather than bolting on the next form of tech debt.

Khan's team enforces company-wide design baselines at the provisioning layer instead: disciplined index design, regular execution plan reviews, consistent standards across every new database. The goal is to keep CPU and storage overhead low enough that heavier analytical workloads can run on infrastructure that already exists. In a regulated healthcare environment, where onboarding a new vendor triggers its own compliance cycle, solving a problem with the infrastructure you already have often saves more time than adding another platform to the stack.

Good tooling won't fix bad queries

AI readiness discourse tends toward the architectural: pipelines, platform consolidation, data mesh. Ask a DBA who spends all day inside execution plans, and the bottleneck is often just the SQL itself.

"You don't always need a special tool for query optimization," Khan said. "Mid-level to advanced SQL knowledge often suffices." Row numbers, offsets, proper join structure, execution plan analysis. These techniques have been in the SQL playbook for decades, but they require a kind of fluency that atrophies when organizations default to buying around performance problems rather than diagnosing them. Deloitte's 2026 State of AI report identified the same dynamic at scale: the skills gap is the number-one barrier organizations cite for AI integration. The people who know how to make existing systems perform are the scarce resource.

Even then, query optimization only gets you so far. In one instance, Khan worked on a reporting database with millions of rows that had become sluggish for analysts. By partitioning the database and restructuring it so queries hit smaller chunks of data, he got performance back to where analysts could actually use the system. Similar dynamic partitioning strategies are becoming standard practice in large warehouses to help teams manage multi-terabyte datasets without overwhelming production systems.

These kinds of partitioning and read-replica patterns used to be the domain of teams with dedicated DBA support and the operational budget to match. Managed Postgres platforms have been collapsing that barrier, making them accessible to teams that would have white-knuckled through full table scans a few years ago.

The spec nobody finished

Even the cleanest partitioning scheme breaks when it's built on incomplete information. "It comes down to the fact that when you're getting requirements, they're not fully clear," he said. Storage gets sized wrong. Clustering doesn't match actual access patterns. Access controls don't reflect how the data will actually be consumed downstream. "Even when we plan everything according to the stated requirements, deployment frequently exposes missing information we didn't anticipate."

At HCSC, operating under HIPAA, those gaps carry regulatory weight. A misaligned access control isn't a performance issue you can patch next sprint. The OCR's proposed update to the HIPAA Security Rule signals where healthcare compliance is heading: toward mandatory zero-trust controls and no more optional safeguards. When databases get provisioned on incomplete specs, the distance between what was built and what compliance requires can take months and real budget to close.

Khan's answer is to include the database team in the conversation at the requirements stage; before the architecture review, before provisioning, before someone discovers on deployment day that the storage assumptions were wrong and the clustering doesn't fit the actual workload. The pattern keeps repeating because the people who understand what goes wrong at the data layer aren't in the room when the decisions that cause those problems get made.

The root of the readiness problem

The AI abandonment stats cited in media read differently depending on where you sit. From the C-suite, it sounds like a technology problem. From inside a database team managing five engines and an endless backlog of optimization work, it sounds like a prioritization problem.

For organizations like HCSC, "AI-ready data" means tuning the queries that should have been tuned a long time ago, partitioning the tables that were always going to need partitioning, and getting requirements right before databases get provisioned wrong. "Knowing the data is the number one key," Khan said. "When teams focus on database fundamentals first, performance typically follows." That depends on people who understand the systems they already have, and those people are getting harder to find. The standalone DBA role is being absorbed into platform engineering and DevOps at the exact moment the demands on the data layer are compounding. The skills aren't obsolete — they're just buried inside job descriptions that no longer carry the title.

The AI initiatives that actually reach production over the next year probably won't share a common platform. They'll share a common trait: someone in the building knew the data well enough to make the existing systems perform, and someone in leadership let them do the work before buying the next thing.