AI Observability Challenges in FinOps as a DBA I was performing research for requested AI work and noticed that I was viewing the risks from a database perspective. As the saying goes in the tech industry, “Once a DBA always a DBA…” As foreign as some of the views were, much of it feels familiar and I simply begin to look at it from the database layer up, not just the AI layer down. Understanding that 98% of FinOps practitioners now manage AI spend, up from 31% just two years ago, is not surprising. AI is everywhere, including databases, applications, DevOps and operations. Seventy-three percent of agentic AI implementations blow their budget, some by more than 2.4x and considering the amount of initial demand to spend tokens and now the blowback on cost, it’s not surprising. One bank burned through a cost model three separate times just to figure out what a mortgage application actually costs to process with an agent in the loop, so the dichotomy is real. What surprised me was realizing how differently it lands for someone who knows a DBA’s main job is keeping Oracle RAC clusters breathing for a bank, or other FinOp organization. We've been doing cost governance the hard way for two decades, especially with the cost of Oracle and we just never called it FinOps. My Life for DecadesEvery Oracle DBA managing mission-critical systems has already fought the exact war this article says enterprises are just now discovering unpredictable consumption, a bill that doesn't map cleanly to a business outcome, and executives who want a single number for something that is actually eleven moving parts. Oracle licensing taught us this lesson before "tokenomics" was a word. Core-based licensing, NUP counts, Database Options that quietly activate and start accruing cost the moment a feature gets touched, RAC node counts that ripple through the entire license calculation, and I won’t even start on management packs. We have spent years building the muscle to say, "here is exactly what this workload costs, what is capacity planning, and here is why," and if we didn’t, an audit would eventually make us. The article's case study, which is a bank needing seven months and three cost-model rewrites to understand what an AI-assisted loan actually costs once you add vector queries, tool calls, human review minutes, and compliance logging, simply reads like a rookie mistake to someone who's had to defend an Oracle Enterprise Edition renewal to a CFO who thinks "the database" is a one line item. So, when the article says the number one requested FinOps capability is granular monitoring of AI spend, and that commercial tooling hasn't delivered it at scale? I do believe it because that's exactly the state Oracle cost was around 2008. We didn't get there by wishing, but because uptime and budget were both non-negotiable at the same time, for years, and the tooling had no choice but to be built in-house or via demand by vendors. Here's My Actual Concern…No, It’s Not CostThe dollar figures in that article don't scare me…remember, I come from the Oracle side of the database world. What scares me is the sentence about only 8% of FinOps teams reporting to a CFO, with the other 92% sitting inside technology orgs and because I know exactly what that org chart produces. It produces a world where the person accountable for uptime is also, by default, becoming accountable for margin, without anyone formally handing them that job or the tools so they can produce what they need to be accountable. I was always aware that my team was the last one to get the resources we required to do the job. Resources were for users, not support of the organization and AI is too much a tsunami to let that scenario repeat itself. When an agentic workload starts hammering a RAC cluster with retrieval queries at 3am because nobody throttled it, which I know is already happening today, it’s not because the DBA owns the AI budget, but because they own the database that's now gasping under load it was never capacity-planned for. The article's framing of "the token as a unit of corporate currency" is cute until you realize the vector database absorbing that agent's retrieval traffic doesn't bill in tokens. It bills in CPU/GPU, I/O, and memory, which are the resources DBAs have spent their careers optimizing from this type of undisciplined growth. We’ve been the guardians effectively ensuring that growth was justified before it became a budget line item. The mortgage case study buried the number that should worry anyone reading this: token cost was only 22% of the total per-loan AI cost. The other 78% included tool calls, vector queries, human review, compliance logging and all of that ends up as infrastructure. That's our world, not the model vendor's and nobody in that “73% over budget” group was thinking about database capacity planning when they scoped the pilot; they were thinking about the model bill, because that's the number that shows up on a slide. What Lets Me ExhaleThe truth is it’s not a smaller number and a more honest truth is that DBAs again need a seat at the table before the workload ships, not after it's already melting a database to ensure that we optimize, not just functionally achieve a goal of innovating to ensure the organization doesn’t go broke or go down before they reach the finish line. Specifically, I’d like to see three things as part of organization’s goals when AI and databases are involved: A pre-production cost and capacity review that includes the database, not just the model. The article's own 90-day framework calls for a "90-day cost projection signed by both engineering and finance before launch." Great, but the projection doesn't include a capacity plan signed by whoever owns the database tier, it's incomplete. Governance that treats database load as a first-class guardrail, the same way token budgets are becoming one. NVIDIA capping engineer token spends and Chamath instituting token caps at portfolio companies is the same instinct DBAs have applied to session limits, resource consumer groups, and I/O throttling for years. Someone above me, not just beside me, who can see both ledgers. The article calls the 8% number the real headline, and I agree, but I'd go further: even inside technology orgs, databases and AI platform engineering often don't share a governance table. I don't need to own the AI budget. I need whoever does own it to understand the database platform as part of the requirements. History repeats itself, but with AI, it’s moving at the speed of light. Main functionality is part of every mission critical database and to forget that in the light of AI innovation and negligence about efficiency and cost is a penchant for disaster. The FinOps world is currently writing about how many times it’s learning and relearning this. As critical as these workloads are, it’s time to stop and mature. We’ve always had a problem seeing the data ecosystem and AI is dependent upon it as most other systems are. Source: AI FinOps in 2026: 73% Blow Budget, 98% Now Track, Rajesh Beri, The Daily Brief Peace out, DBAKevlar Join the debate, and respond to the editorial on the forums | 
