AI cost engineering looks like a new discipline. For a database engineer, it is mostly a familiar one wearing different units. The mental model that finds a bloated index or an oversized instance is the same one that finds a wasteful prompt or an over-large model.

Problem

AI spend is becoming a top infrastructure line item, and most orgs have nobody who owns it the way a DBA owns the database bill. Product engineers ship features; finance sees a total; no one connects usage to cost at the unit level. The role is open — and database engineers keep assuming it belongs to someone else.

Why it matters financially

For the engineer, this is leverage. AI cost work is high-visibility, under-supplied, and directly tied to dollars an executive cares about. For the org, putting cost-literate engineers on AI spend is the difference between a forecastable line and a quarterly surprise. The same person who can say “this query costs the business $4k/month in I/O” is the person who can say “this prompt design costs $9k/month in tokens” — and both sentences change budgets.

Technical root causes (why the analogy holds)

The transferable model is: measure usage → find structural waste → quantify the opportunity → sequence the fix against risk. The specifics map cleanly:

  • pg_stat_statements ↔ per-call token logging. Both answer “where does the cost concentrate?”
  • Indexes ↔ embeddings/retrieval. Both are precomputation that trades storage/compute for query speed — and both are routinely over- or under-built.
  • Caching (buffer cache, result cache) ↔ prompt caching / result caching. Same idea: don’t pay twice for the same work.
  • Instance right-sizing ↔ model right-sizing. Don’t run a frontier model (or an r6g.4xlarge) for a workload a smaller one serves.
  • Query plans ↔ context construction. Both are about giving the engine exactly what it needs and no more.

Where the analogy breaks

One place it does not transfer: quality is a continuous tradeoff with no database equivalent. Dropping an unused index is free; dropping to a cheaper model might lose accuracy. AI cost work therefore always needs a quality guardrail — an evaluation set you check before and after every change. A DBA’s instinct to optimize aggressively must be paired with that guardrail.

Review checklist (a DBA’s first look at AI spend)

  • Is there per-call logging of tokens and model, tagged by feature? (Your pg_stat_statements.)
  • What share of calls use a model larger than the task needs? (Your right-sizing pass.)
  • Is anything recomputed that could be cached? (Your buffer-cache instinct.)
  • Is retrieved context larger than the model needs? (Your “why is this a seq scan?” instinct.)
  • Is there an evaluation set guarding quality before cost changes ship?
  • Who owns the AI cost number, and do they see it weekly?

Example findings

(Illustrative.)

  • A database engineer reviewing an LLM feature spotted that retrieval returned 20 chunks where ranking showed the answer was almost always in the top 5 — the same “you’re scanning more than you read” pattern they’d flagged in SQL a hundred times.
  • The same engineer recognized an uncached static prompt as exactly the repeated-work pattern a result cache solves on the database side.

Actions to take

  1. Claim the unit-accounting work. Add per-call cost logging; it is the AI analog of enabling statement stats, and it makes you the person with the data.
  2. Apply your right-sizing playbook to models, with an evaluation set as the guardrail.
  3. Bring caching and “don’t recompute” instincts to prompts and retrieval.
  4. Frame findings in dollars and risk, exactly as you would a database cost review.

A 30-day ramp

  • Week 1: read your provider’s pricing and token mechanics; add per-call cost logging.
  • Week 2: build a small evaluation set for one feature; baseline its quality and cost.
  • Week 3: run a model right-sizing and caching experiment behind the guardrail.
  • Week 4: write it up in impact × effort × risk terms — the same report you’d hand to an engineering manager after a database review.

Run the database review that proves the model first. See How to Run a Database Cost & Reliability Review, grab the free 30-Point Checklist, or talk to AKS about a Database Cost & Reliability Review — and see the Acme SaaS sample report for what one delivers.