The Infrastructure Challenge behind Production AI

The panel's central claim is blunt: building models is largely a solved, outsourced problem, while running the systems underneath them is not. An AI feature does not simply add load to production; it changes the shape of the load. A single user action can expand into a loop of model calls, tool calls, code execution, retries, and database writes, so request counts stay flat while cost and contention explode. Every operational assumption built for human-driven traffic — autoscaling, capacity forecasting, rollback, budgeting — degrades under that shape change.

This is a 63-minute InfoQ Live roundtable published on 1 July 2026, moderated by Renato Losio (InfoQ staff editor, cloud expert, AWS Data Hero) with four practitioners: Simerus Mahesh (founding engineer at Forge, AI security and agent governance; previously Meta, Google, PlayStation), Alex Infanzon (senior systems engineer / solutions architect at Cockroach Labs, long-time DBA), Meryem Arik (co-founder and CTO of Doubleword, an inference provider working on model serving since before ChatGPT), and Luca Bianchi (CTIO at MESA, building software for highly regulated sectors).

Because this is a panel rather than a single-thesis talk, these notes reorganise the discussion into a teaching sequence and keep each claim attributed to the panelist who made it. Several speakers work for vendors in the space, so their product-adjacent claims are labelled as such. Points marked Context are supplementary explanation added for readers unfamiliar with the terminology, not statements from the panel.

What You Will Learn

• Why token spend, energy, and compute — not model quality — are the binding constraints panelists see in production AI.
• How agent workloads break the "just autoscale it" reflex and why bounding must precede elasticity.
• Why capacity planning for inference is, in Arik's view, a job most companies should not attempt themselves.
• How teams are approaching AI cost per developer, and why ROI, not absolute spend, is the right unit of judgment.
• Why the database is becoming an agentic control plane holding telemetry, identity, audit trails, workflow state, and memory.
• Why rolling back an agent is a compensation problem rather than a deployment problem, and what to design in before launch.
• Which piece of infrastructure wisdom each panelist now considers obsolete.

The Bottlenecks Panelists Actually Hit

Token Cost Grew Far Faster Than Predicted

Arik said her company made two bets four years ago: that open-source models would have to win on cost, performance, and privacy grounds, and that token cost would become a major issue as spending scaled. She considers both directionally confirmed. What surprised her was the pace. The industry talks about Jevons Paradox comfortably in the abstract, but living through it is different: she had anticipated aggregate token cost rising roughly 10x per year and observes closer to 100x for most organisations.

Context. Jevons Paradox is the observation that improving the efficiency of a resource can increase, not decrease, total consumption of it, because the lower unit price unlocks far more use. Applied here: as price per token falls and models get better, teams route far more work through them, so the bill rises anyway.

The operational consequence Arik draws is the interesting part. If you designed an application for production a year ago, you probably designed it for an order of magnitude less scale than it will need next year. That gap is not a provisioning detail; it invalidates architectural decisions that assumed a stable growth curve.

Energy, Siting, and the Legacy Data Layer

Infanzon agreed that token cost is breaking budgets at companies of every size, then added two constraints below it. First, the industry expected GPU supply to be the limit, but energy consumption in data centres is now equally binding — if you want your own data centre you have to plan years in advance around locations with sufficient power. Second, one level up, the legacy data layer is becoming expensive to maintain, because traditional databases were not designed for the high-velocity, high-constraint demands of AI workloads. His proposed answer is distributed SQL, which is his employer's product category and should be read as a vendor position rather than a neutral finding.

He also described what that data layer is now storing: agent usage data, token behaviour, memory consumption, and traceability records. The database is no longer just where the application's business data lives; it is where the evidence of agent behaviour lives.

Compute, and Agents That Outlive Their Parents

Mahesh, drawing on data-centre optimisation work where he tuned power consumption directly, offered a partly dissenting view: in his anecdotal experience power was rarely the practical bottleneck, whereas compute was, at every company he worked at that ran its own data centres. Companies pour effort into configuring their own Kubernetes environments to manage vertical and horizontal scaling of these workloads.

His most concrete technical observation concerns process lifetime. Agent systems do not follow a neat thread-style model; they behave more like a process model. If an agent spins up a sub-agent, that sub-agent can keep running even after the parent agent dies. He drew the explicit parallel to operating systems and orphaned processes. That matters operationally because compute can remain committed after the user-visible response has completed, so utilisation no longer correlates with the request lifecycle you monitor.

External Endpoint Availability Changes by the Hour

Bianchi identified the resource he runs out of first: availability of external systems. His comparison with databases is the sharpest framing in the panel. A provisioned database scales up or down with a known latency, and if you get throttled the figures are clear enough to plan around and mitigate. An external AI endpoint is not like that. You send a message expecting an answer in around 30 seconds, and instead the answer can fail, arrive three or four times slower than expected, or arrive truncated.

He gave a specific failure he experienced: nothing changed in his system between noon and 3 p.m., but the United States woke up, began consuming the same endpoints and the same constrained resources, and his requests were throttled. The variable was the clock, not his code. For teams whose only knob is a third-party API key, this is a genuinely new class of dependency risk.

Capacity Planning You Probably Should Not Do Yourself

Asked how to plan capacity for a workload that can jump tenfold overnight, Arik's answer was unusually direct for a vendor in the inference business, and she named her own commercial interest in it: it is so difficult that you should probably not try unless it is your job.

Her reasoning is historical. A key motivation for open-source model inference used to be self-hosting. But the job of inference has grown too large for most companies to attempt at any serious scale, because you inherit a full capacity planning operation plus the construction of an entire inference stack — far more work than most businesses want to own. She therefore argues it is better left to inference companies.

She is candid about what you trade away. Moving to multi-tenant endpoints buys you a noisy neighbour problem: your endpoints get a little too slow when the US wakes up, exactly the effect Bianchi described. Her defence of the trade is that good inference providers do capacity planning better than you will, and that there is not enough compute in the world to satisfy demand anyway, so even the best provider will sometimes exhibit noisy neighbour effects. She noted her own company is somewhat insulated because it mainly serves large-volume and long-running agent tasks rather than latency-sensitive interactive traffic — a useful hint that your workload profile determines how badly multi-tenancy hurts you.

Context. "Noisy neighbour" describes shared-infrastructure contention: one tenant's load degrades another tenant's latency or throughput because they sit on the same physical capacity. A "cold start" here means the delay to load model weights onto a GPU before it can serve traffic, which is why providers cannot instantly materialise capacity on demand.

Arik later described the same problem from the provider side when asked about scaling down. If you offer 20 different models on fixed GPU capacity, you must constantly swap models in and out and scale instances up and down to match demand. She noted an active research community working on faster cold starts and faster scale-ups. Most teams, she observed, have simply handed this problem to a provider — Losio's summary was that "they give away the problem" — but it remains a very real engineering problem for someone.

What AI Costs Per Developer

Infanzon's answer began with the honest "it depends" — on procured infrastructure, model choice, and application design — and then produced the panel's most concrete cautionary example. He cited Uber publishing in May that it consumed its entire yearly AI budget in the first four months of the year, at a rate he recalled as roughly $200 to $500 per user. The trigger, in his telling, was incentive design: the company encouraged AI use, including leaderboard-style games where heavier AI users ranked higher, and consumption multiplied. Losio's summary — wrong incentives pushing cost — is fair, and it is a reminder that a FinOps failure can originate in a gamification decision rather than an architecture decision.

Infanzon added a behavioural reason costs escape control: agents are eager to help. When something does not work they loop, retry, and try a different route. That creativity is precisely what consumes tokens and resources. His conclusion is that the useful question is not what the cost is today but how you make engineering organisations aware of and responsible for it.

Arik pushed back on treating spend as inherently bad, and her framing is the most useful part of this section. She reported the range varying wildly: friends at companies like NVIDIA whose token spend runs about $15,000 per month per team member, which those teams do not mind because it replaced hiring and increased velocity; other companies spending $200 per month per employee and complaining; and Uber's cap, which she recalled as around $1,500. Her position is that you should spend as much as you are getting value from — if $50,000 a month per employee is genuinely productive, spend it. The failure mode is not high spend but uncaptured value. She acknowledged the "token maxing" pathology Infanzon raised, where people put things on loops and do incredibly stupid things to solve basic problems. Infanzon's closing note is the mirror image: without a measure of ROI, you are simply burning money.

Note these figures are the panelists' recollections of specific companies and their own anecdotes, not survey data. Treat them as illustrative ranges.

Governance Is the Mechanism, Not Willpower

Mahesh, whose company builds a governance platform for exactly this and who flagged that interest, described what an implementation actually requires: an observability wrapper around every agent deployed or run inside the organisation. He pointed out a practical starting point that costs nothing — telemetry and logs for Claude Code sessions and Codex sessions are already written to the local filesystem, so a native in-house solution can read them directly.

He then broadened governance beyond cost to data egress. Organisations do not want engineers doing whatever they like, because an engineer might paste production code or API keys into a model. Governing what gets fed into models is a distinct control problem from governing what agents spend. His honest assessment of build-versus-buy: a naive in-house solution is achievable and somewhat hacky, whereas something robust takes considerable time to build.

Sensitive Data, Locality, and Hybrid Model Routing

Bianchi's answer on production data is that no single solution fits, because the required degree of confidentiality varies by customer, by sector, and by data type. He described two patterns he has seen.

The first is full self-hosting, chosen by customers who want all data management and processing inside their perimeter. He judged it hard to plan for, for two compounding reasons: the price of the underlying hardware is constantly changing, and model accuracy and availability are changing too. Committing now to a specific model — some version of Qwen, say — for the next six months means committing without knowing what will exist in six months. His verdict is that 100% data locality is difficult.

The second pattern, which his own company uses, is a tiered model architecture: local models handle the most sensitive, non-anonymised data, while an anonymisation layer strips sensitive fields so that the remaining work can be sent to frontier models. This balances data security and locality against cost and against the difficulty of six-month forecasting.

Context. The security of this pattern rests entirely on the anonymisation layer. Re-identification from residual quasi-identifiers, and leakage through free-text fields that a redactor does not recognise, are the standard failure modes. The panel did not discuss how to validate such a layer; treat it as an architecture requiring its own testing and audit rather than a solved control.

The Database as Agentic Control Plane

Infanzon's recurring thesis, which he stated twice, is that over the last couple of years the database has shifted from being the repository at the back to being the control plane. His justification is an inventory of what now lands there:

Two properties follow from this, in his account. First, geographic distribution: agents in Italy should read from co-located nodes and get local latency, which he frames as an argument for a database distributed across regions but presented as a single logical database. Second, and more strongly stated, strong consistency. He argued you cannot allow eventual consistency for this class of application, because agents will act on wrong information and unwinding what they then trigger is extremely difficult. Both points are the distributed-SQL vendor argument and should be weighed accordingly, but the underlying failure mode he describes — an agent making an irreversible decision from stale state — is real regardless of which database you choose.

Bianchi added the cultural version of the same shift. Databases used to be designed for humans; he cited Hernandez's Database Design for Mere Mortals as the emblem of that era, where the goal was to let developers design schemas so data could be retrieved and shown to people. Now agents retrieve data, possibly across several databases at once, and the constraint that used to matter — the cognitive load of a team keeping too many different databases in their heads — may become less important. He agreed that the database is where everything eventually fails.

Infanzon's clarification is worth preserving, because it is the panel's fairest statement of the problem: the database is not failing, it is being blamed. The real issue is that so many agents are accessing it that a DBA cannot keep up with the demand. His employer's response is to add AI capabilities inside the database so an agent can monitor in real time why performance is stalling, why writes are slowing, and why latency is rising. He explicitly connected this to Oracle's "autonomous database" messaging from the early 2000s, arguing that putting agents inside the database is the realisation of that old idea. That is a vendor roadmap claim, not a demonstrated result.

Rollback Becomes Compensation

Losio's rollback question exposed the deepest gap between traditional and agent operations, and Mahesh gave it the clearest structure. Some rollbacks remain clean and conventional: a system prompt, a model version, or a feature flag can be reverted with standard procedures.

Rolling back an AI capability that has already taken action is much harder, because the output is not just text. By the time you decide to revert, an agent may have created files, changed configuration, opened pull requests, called cloud APIs that are not meaningfully reversible, updated state in a database or a queue, or triggered a downstream CI/CD workflow such as a Jenkins job. At that point, in his words, rollback becomes less about reverting a deployment and more about compensating for side effects.

His prescription is to design for rollback before launch:

• Feature flags to disable a capability without a deploy.
• Dry-run modes so an agent can propose actions without executing them.
• Approval gates on consequential steps, tying rollback design back to governance.
• Idempotent operations, so retries do not multiply effects — the same discipline that ACID-compliant database work demands.

He was explicit that there is no clean general answer given the variety of workloads, and that the cleanest rollback is usually prevention: stop irreversible actions from happening automatically in the first place.

Bianchi added a distinction that is easy to miss. Conversation history is easy to save and recover, and the effects of an action are often reversible — if an agent ran a query you can undo that query. What cannot be rolled back is the reasoning process that led the agent to use one tool rather than another. That residual uncertainty is intrinsic to agentic systems, and his suggestion is to handle it with guardrails and by focusing control on the effects of actions rather than on the deliberation that produced them.

Infanzon extended this to multi-agent error propagation with a customer example. Working with a very large credit card provider, the concern is that one agent acting on stale or wrong data passes a result to another agent, which acts and triggers two more agents, whose downstream actions persist results somewhere. Every one of those records is wrong because it derives from a wrong initial assumption. His team's response is partnerships with two other companies:

• DBOS, which tracks agent workflow state in the database so the exact steps an agent took can be traced back, rolled back, and fixed.
• Memori, which persists agent memory state in the database and uses it to provision better prompts by injecting what agents already learned and did previously. He noted that vector search inside the database is what makes finding similar past situations possible.

Losio pushed back on the last point — similarity search is not technically a rollback — and he is right. Retrieving analogous past episodes helps an agent avoid repeating a mistake; it does not undo one.

An audience member asked whether a real-time Saga pattern built up over the conversation could enable rollback. Infanzon's answer: the Saga pattern works if you can trace every step and every action of every agent and record those updates, so that when a model or agent fails you can revert and trace back. He framed the difficulty by contrast with the past, when everything was in the database log and rolling back a transaction was straightforward. Today you are not rolling back a transaction; you are rolling back a series of actions spread across different agents holding different states. Bianchi's non-reversibility caveat applies on top: some of those actions can only be compensated, not undone.

Context. The Saga pattern coordinates a long-running, multi-step transaction across services by pairing each forward step with an explicit compensating action, since a single distributed ACID transaction is not available. Applying it to agents means every tool call needs a defined inverse — which is exactly the part that fails for actions like sending an email or calling a third-party API.

Who Absorbs the Pain

Asked which role suffers most, Mahesh nominated the on-call SRE, with platform engineers close behind, and gave a precise mechanism. In a normal product, traffic growth ties to user growth or a known launch. With AI systems, the same number of users can suddenly produce far more load, because a changed prompt, a newly added tool call, or simply more context can make an agent loop more aggressively and multiply infrastructure demand tenfold. Production can break while user traffic is completely normal, and request count may not even look alarming — each request is just doing far more work behind the scenes. The agent runs longer, calls more tools, and creates more state. The on-call engineer is therefore not handling more traffic but a workload whose cost and behaviour can change overnight. Hence, as he put it, the lack of sleep.

Infanzon's version, from years as a DBA, is that the database is always guilty until proven otherwise. His examples of work landing on the data platform team are specific and worth internalising as a planning list:

• An engineer decides to change the database's embeddings, and the data platform team has to migrate a schema with 40 million rows or more.
• The security team flags a governance gap in agent access, and the data platform team has to build the audit trail.
• The SRE is paged at 2 a.m. because an agent loop is hammering the database — and the DBA is on the call too.

The Infrastructure Wisdom That Stopped Being True

Each panelist named one belief that AI has invalidated.

Arik: software unit economics. Investors liked software businesses because margins were excellent and scaling was cheap, since infrastructure cost was not the driver. That is no longer true. Infrastructure cost is now so large that it forms a major part of the cost base, and in her view 70–80% margins are simply not possible anymore. Infrastructure has become a key cost driver — perhaps the key cost driver — which is a genuinely new phenomenon for software businesses.

Mahesh: "if demand spikes, autoscale through it." That reflex worked when workloads were human-driven and bounded by click and access patterns. Now one user action triggers a loop of model calls, tool calls, sandboxed code execution, retries, database reads and writes, and cloud API calls. If that loop is inefficient or misconfigured, autoscaling does not solve the problem — it amplifies it, turning a product bug or a small inefficiency into a huge bill or a cascading outage. His replacement rule: before you scale AI workloads, you must bound them. Put limits on runtime execution, tool calls, retries, multi-tenancy setup, sandbox isolation, and overall blast radius. He was careful not to dismiss the cloud — elasticity is still genuinely useful — but insisted bounded autonomy comes first.

Infanzon: plan for elasticity, not for expected growth. He used to do capacity planning against a growth forecast; with agentic AI he considers that impossible, because he cannot predict what workload agents will generate or state that a given amount of database infrastructure suffices. The better goal is an architecture that is elastic, combined with guardrails in the agents themselves.

Mahesh and Infanzon then disagreed productively about ordering, and the disagreement is the most useful exchange in the panel. Mahesh argued elasticity should come second: bound your agents first and ensure the blast radius is acceptable, because on a cloud like AWS you effectively have infinite compute and the only limit is cost. Autoscaling machinery — Karpenter provisioning more nodes, or more pods spinning up in Kubernetes — will happily manufacture compute for misconfigured or unwanted behaviour, running up the bill or causing slowness.

Losio framed the resulting squeeze precisely: teams complain simultaneously that their AI workload can trigger a huge bill, and that cloud providers, constrained by the same capacity shortage Arik described, impose soft and hard limits that are often too low for what they want to run — for instance when accessing models through a service like Bedrock. You can be over-provisioned in cost and under-provisioned in capacity at the same time.

Infanzon closed with his employer's architectural response: separating compute from storage so each can be scaled independently, which is a common distributed-database design goal rather than a unique property.

Architecture And Data Flow

The panel does not describe one system, but its concerns compose into a single control loop: bound the agent, observe it, persist its workflow and memory, and keep the ability to compensate for what it did.

flowchart TD
    U[User or scheduled trigger] --> G{Governance and bounds}
    G -->|reject or require approval| H[Human approval gate]
    G -->|allow| A[Agent loop]
    H --> A
    A --> M[Model inference
self-hosted or provider endpoint]
    M -->|throttling, latency, truncation| A
    A --> T[Tool calls]
    A --> S[Sub-agents
may outlive parent]
    T --> SE[Side effects:
files, cloud APIs, PRs, CI jobs]
    A --> D[(Control-plane database)]
    D --> W[Workflow state]
    D --> ME[Memory and past outcomes]
    D --> AU[Audit log and agent identity]
    D --> TE[Telemetry, tokens, cost]
    W --> R{Failure detected}
    R -->|reversible| RB[Roll back transaction or config]
    R -->|irreversible| C[Compensating action]
    ME -->|vector similarity search| A
    TE --> FO[Cost and ROI review]

Reading the diagram against the discussion: the governance node is Mahesh's "bound before you scale"; the return edge from inference is Bianchi's throttled, slow, or truncated responses; the database is Infanzon's control plane; the split at failure detection is the rollback-versus-compensation distinction; and the memory feedback edge is Infanzon's DBOS and Memori pattern, which improves future prompts but does not undo past actions.

Trade-offs And Limitations

Self-hosting versus provider endpoints. Self-hosting gives data locality and perimeter control, which Bianchi's regulated customers demand, but forces you to forecast hardware prices and model capability six months out — a forecast he considers unrealistic. Provider endpoints remove the capacity-planning burden Arik says most companies should not carry, at the price of noisy neighbour latency, time-of-day throttling, and dependence on someone else's soft and hard limits.

Bounding versus elasticity. Bounds prevent runaway loops from converting a bug into a bill, but every bound is a potential false positive that stops legitimate work. Elasticity absorbs genuine demand but amplifies misconfiguration. The panel's implicit resolution is sequencing: bound first, then make the bounded system elastic.

Strong consistency versus availability and cost. Infanzon's insistence on strong consistency for agent state is well motivated by cascading wrong-data failures, but globally synchronous consistency has real latency and cost implications that the panel did not quantify, and it is also the design his employer sells.

Governance versus developer velocity. Observability wrappers and approval gates give you cost attribution and data-egress control, but Mahesh conceded that in-house versions are hacky and robust ones take substantial time to build. Approval gates also convert autonomous agents into semi-manual workflows, which erodes part of the value being paid for.

Cost caps versus value capture. Arik's position is that spend should track value, not a fixed ceiling; the Uber example shows what happens without a ceiling. Both are true, which means the real control is measurement. Without a credible ROI measure, as Infanzon said, a cap is arbitrary and no cap is reckless.

Rollback is not fully achievable. Even with Saga-style step tracing, DBOS workflow persistence, and idempotency, Bianchi's point stands: the reasoning that produced an action cannot be reverted, and Mahesh's list of side effects includes calls that have no inverse. Prevention is not a fallback here; it is the primary control.

Vendor perspective. Three of the four panelists represent companies selling into this problem — inference serving, distributed SQL, and agent governance respectively. Their descriptions of the problems are consistent with each other and with the moderator's independent framing, but their proposed solutions naturally match their products.

Practical Takeaways

The panel closed by asking each speaker for something a practitioner could act on immediately.

• Trace one production AI workflow end to end (Mahesh). He explicitly advised against starting with a full architecture redesign, since that evolves constantly and migration is a large undertaking. Instead pick one workflow that matters, map the complete path of model calls, tool calls, and database queries, then ask: what is the maximum runtime? What is the maximum number of tool calls? What happens if a dependency slows down? What happens if a model retry goes wrong? The goal is to find where the system is unbounded. You will not fix everything, but you will typically identify one or two concrete things to change first.
• Reconsider your architecture in light of AI's impact on infrastructure (Bianchi). He recommended Neal Ford's work on evolutionary architecture for principles that survive rapid change, and framed the goal as staying in business while databases with shared compute, new agents, and new models keep arriving. Build an architecture that can evolve and absorb advances as they appear.
• Re-evaluate open-source models if you have not in 6–12 months (Arik). She reported large capability gains recently, citing GLM 5.2 as an example, and described them as much cheaper with good latency depending on the inference provider. Note she runs an inference company and has a stated four-year bet on open-source models winning.
• Demand failure-mode evidence from your data infrastructure vendor (Infanzon). Ask vendors to show how the system behaves under failure, not under a predefined load. He argued benchmarks like TPC-C are too constrained because they assume a system running perfectly all the time. The questions he would ask: what happens when the network partitions? When a node goes down? When someone needs a schema change — can it be done online? When an entire region fails? When the database software is being upgraded? AI agents will stress the infrastructure, so the benchmark that matters is behaviour under pressure.
• Instrument agent cost before you try to control it. Start with the telemetry you already have — Mahesh noted Claude Code and Codex session logs are written to the local filesystem — and build attribution before setting caps, so limits reflect value rather than guesswork.
• Audit your incentives, not just your architecture. The Uber example Infanzon cited traces a budget overrun to leaderboard-style encouragement of AI use. Check whether anything in your organisation rewards token consumption as a proxy for productivity.
• Design idempotency and dry-run modes into tools now. Retry loops are the default agent behaviour under failure; tools that are not idempotent turn that behaviour into duplicated side effects that no rollback can cleanly undo.

Key Terms

• Agentic AI — systems where a model plans and executes multi-step work by calling tools, rather than only returning text to a user.
• Blast radius — the maximum scope of damage an unbounded or misbehaving component can cause before something stops it.
• Bounding — imposing hard limits on agent runtime, tool-call count, retries, and isolation, as distinct from scaling capacity to meet demand.
• Cold start — the delay incurred loading model weights onto a GPU before an inference endpoint can serve traffic; a key limit on how fast providers scale.
• Compensating action — an explicit forward operation that offsets an already-executed step whose effects cannot be reversed.
• Distributed SQL — a relational database distributed across regions but presented as one logical database, aiming for local latency with strong consistency.
• Eventual consistency — a model where replicas converge over time; readers may temporarily observe stale data, which the panel argued is dangerous for agent state.
• Idempotency — the property that repeating an operation produces the same result as performing it once, making retries safe.
• Inference provider — a company that hosts and serves models on managed, usually multi-tenant, infrastructure.
• Jevons Paradox — efficiency gains in using a resource can increase total consumption of it by making more use economically viable.
• Karpenter — a Kubernetes node-provisioning autoscaler that adds compute in response to pending workloads.
• Noisy neighbour — performance degradation caused by other tenants sharing the same underlying infrastructure.
• Saga pattern — coordination of a multi-step distributed transaction by pairing each step with a compensating action instead of relying on a single atomic transaction.
• Token maxing — the pathology of looping models excessively on trivial problems, consuming tokens without producing proportionate value.
• TPC-C — a long-standing OLTP benchmark, criticised here for measuring throughput on a healthy system rather than behaviour under failure.

Reference: The Infrastructure Challenge behind Production AI