Background

In 2016 Capital One decided to go all-in on the public cloud. In 2017 it became one of Snowflake's earliest large-scale adopters, moving its entire data workload off Teradata and on-prem hardware. The payoff was immediate and enormous: queries that took three hours finished in minutes, and a small central team found itself supporting somewhere between six and seven thousand analysts running millions of queries a day. The warehouse eventually grew from roughly 200 terabytes to 50 petabytes.

The scale is not an exaggeration for effect. Snowflake's own S-1 disclosed that Capital One accounted for approximately 17% of its revenue in FY2019 and 11% in FY2020 — the only customer named above the 10% concentration threshold, listed as a risk factor in the IPO. Our data bill was material enough to appear in another company's SEC filing.

And that was the problem. Capital One's engineering blog puts the causal chain plainly: the new scale and speed "unlocked new opportunities... But without proper controls in place, costs associated with data consumption escalated quickly across the organization and good data governance became more difficult." Then the part that decided everything else — "With a lack of tools in the market that could help us meet our goals, our team of talented engineers began creating internal tools."

There was nothing to buy. So it got built in-house, starting in 2019. I worked on that platform during its internal phase — supporting the pilot data-warehouse SaaS and driving feature work on its web app — alongside my main project, the CCPA fulfillment pipeline. In June 2022, after I'd left, Capital One launched Capital One Software and shipped that internal tooling as Slingshot, its first commercial product.

Challenge

Everyone's first instinct is that this is a dashboard. Query the billing data, chart it, done. Here's why the data cloud doesn't cooperate:

• Elasticity solved the concurrency problem and deleted the thing that policed waste. On Teradata, contention was the budget: fixed capacity meant a bad query slowed everyone down, got noticed, and got fixed. Scarcity was the feedback loop. On Snowflake, storage and compute are decoupled — a bad query just quietly spins up more credits and nobody else's queries slow down at all. The elasticity that made the platform great is the same property that removed the only natural signal that something was wrong.
• Sizing mistakes are geometric, not linear. Snowflake credit consumption doubles with every warehouse size step — X-Small burns 1 credit/hour, Large burns 8, 4X-Large burns 128. An X-Large that should have been a Small isn't 20% wasteful; it's 8× wasteful. And the default size depends on which interface you happened to use — CREATE WAREHOUSE defaults to X-Small while the UI defaults to X-Large, a 16× spread decided by a click. Humans eyeballing warehouse sizes is a losing game.
• The meter is three hours stale. This is the deep one. Snowflake's authoritative usage data lives in ACCOUNT_USAGE, and it is not real-time: QUERY_HISTORY lags ~45 minutes, WAREHOUSE_METERING_HISTORY lags three hours, and cross-account ORGANIZATION_USAGE can lag a full day. A runaway 4X-Large burning 128 credits/hour can incinerate roughly 384 credits before the spend is even visible, let alone actionable. The alternative source, INFORMATION_SCHEMA, has no latency but limited retention and excludes dropped objects. You can have fresh data or complete data — not both. Anything credible has to reconcile the two and survive the hours where they disagree.
• The only native lever is "off." Snowflake's built-in control is resource monitors, and per Snowflake's own docs they can't track serverless consumption, can't track storage at all, can't enforce hourly granularity, and can't do cost attribution in any form. Their actions are limited to notify, suspend, or suspend-immediately. There is no native "make this cheaper" — only "tell someone" or "break it." Worse, only ACCOUNTADMIN can create them, which is the bottleneck problem in miniature: the most cost-relevant control in the platform is gated behind its most privileged role, so it can't be handed to the teams actually spending the money.
• Nobody owns the cost. Snowflake has no native concept of which team a dollar belongs to. Warehouses are flat, account-level objects — no org hierarchy, no cost centers. Answering "what did Fraud spend last month?" means inventing an attribution model out of naming conventions, query tags, and mapping tables, then maintaining it as an external system of record. That's not a missing feature; it's an entire data model the platform declines to have an opinion about.
• Even "just suspend idle warehouses" has no correct answer. Snowflake drops the local cache when a warehouse suspends. Suspend aggressively and you save credits but cold-start every query; suspend lazily and you keep the cache warm and pay for idle. If queries arrive every 30 minutes and auto-suspend is set to 10, you get the worst of both — you pay for idle and still lose the cache. The right value depends on the shape of each warehouse's workload, which is why this is a recommendation problem rather than a config standard.
• Self-service makes spend grow faster than adoption. Every new warehouse is an independent cost center with its own idle floor, multi-cluster warehouses scale out invisibly, sizing errors compound geometrically, the cost signal arrives hours late, and the only enforcement is one nobody opts into. Capital One's own numbers show the shape: the warehouse grew 250× while cost per query fell 43%. Unit costs dropped and total spend still exploded. "Just optimize your queries" does not touch this.

Solution

The strategic bet was that a central team should stop being a gatekeeper and start being a platform: let six or seven thousand analysts provision their own infrastructure, but make the guardrails structural rather than procedural. As Capital One's Salim Syed framed it — "We had a small team supporting 6,000 to 7,000 users who were running millions of queries a day. We didn't want to be a bottleneck. We wanted to empower business people to manage their own infrastructure but with best practices and guardrails built-in."

Reading the meter without touching the data

The platform's entire relationship with Snowflake is through the metadata plane: it reads the ACCOUNT_USAGE and ORGANIZATION_USAGE schemas — query history, metering history, warehouse events — rather than proxying queries or touching customer data. That's a deliberate architectural choice with a compliance dividend: a cost tool that never sits in the data path is one a bank can actually run against its own regulated warehouse, and it's why the product was later deployable inside other companies' perimeters as a Snowflake Native App.

The services underneath

The backend was containerized services on AWS — Docker images running on EKS and Fargate, written in Java Spring Boot and Python, with DynamoDB behind them and protobuf/gRPC for typed service-to-service contracts. That shape is a good fit for the problem: ingesting metering data is bursty and scheduled rather than steady, so serverless containers size to the work; and gRPC's schema-first contracts matter when the thing you're passing between services is billing data that has to reconcile exactly.

The surface analysts actually touch

The web app — React — is where the platform either succeeds or fails, because the entire premise is self-service. Guardrails only work if the path of least resistance runs through them. That means warehouse templates with governance pre-baked, so provisioning correctly is easier than provisioning badly; approval workflows that route a request to the line of business that owns the budget instead of to a central queue; and cost dashboards that attribute spend to a team rather than to an anonymous warehouse. I drove feature work on this app.

What it ended up doing

Publicly, Capital One describes four internal capabilities that became the product: a self-service portal so non-technical users could request access and warehouses without going through the central team; cost and performance dashboards breaking down credit usage and waste by line of business; dynamic warehouse scheduling that changes size, cluster count, and scaling policy on custom schedules rather than leaving one setting to be wrong all day; and automated governance via pre-configured templates and custom approval workflows.

Notice what those four have in common: none of them are "a report." Each one either moves a decision to the person who owns the money, or removes the decision entirely.

Results

Capital One has published the outcome of the internal platform: 27% savings against projected Snowflake costs over three years starting in 2019, 50,000 hours of manual effort eliminated by automated infrastructure management, and a 43% drop in cost per query — all while the warehouse grew 250× to 50 petabytes. Those are the company's own numbers for the tooling overall, not a personal attribution; my part was supporting the platform and its web app during the internal years.

The bigger result is what happened to it. The tool built because there was nothing to buy became Capital One Software's first commercial product in June 2022, launched at Snowflake Summit and now sold to enterprises like Dynata and Capital Rx. Internal infrastructure, built from necessity, externalized — the same arc as AWS, and plausible for the same reason: Capital One hit the data-cloud cost wall years before the market did, because at 17% of Snowflake's revenue there was nobody else standing where they were standing.

Why this matters for a business:

• Cloud elasticity is a spending decision disguised as an architecture decision. The moment compute decouples from contention, waste stops being self-correcting. Every org that moves to a consumption-priced platform inherits this, and almost none of them plan for it — the bill is the only feedback loop left, and it arrives monthly.
• Observability without an action is just an invoice with charts. The native tooling could notify you or break your warehouse, nothing in between. The value was never the dashboard; it was moving the decision to whoever owned the budget, or automating it away entirely.
• Stale telemetry changes the design, not just the latency. Three-hour-old metering means "detect and alert" is structurally too late — the money is already spent. It forces you toward prevention (templates, schedules, right-sizing) over reaction, and that's an architectural consequence of a documented latency number, not a philosophy.
• The best products are the internal tools you were forced to build. Nobody sets out to sell software because they want to. Capital One built this because the market had nothing, at a scale nobody else had reached yet — and being early at unusual scale is exactly what makes internal tooling commercially valuable later.

Conclusion

Slingshot is what happens when a company gets so far out in front of a platform's cost model that it has to build the missing half itself. The engineering problem was never "chart the spend" — it was controlling a system whose meter runs three hours behind, whose only native brake is an off switch, and whose costs double with a single dropdown, all while handing the controls to seven thousand people who don't work for you.

If you're running a consumption-priced data platform and the bill has started outrunning the story you tell about it, that's a solvable engineering problem — and one I've worked on at genuinely uncomfortable scale. Book a call and we'll dig into it.