We Saved $380,000 by Deleting Data

The Dataset Nobody Dared to Touch

Every company talks about becoming data-driven.

Very few companies ever ask whether they have become data-addicted.

The distinction matters more than most executives realize.

During the last decade, cloud platforms have fundamentally changed the economics of storing information. In the era of on-premises data warehouses, storage was expensive enough to force difficult decisions. Teams archived old datasets, deleted obsolete tables, and carefully justified every additional terabyte. Google Cloud changed that mindset almost overnight. Storage became inexpensive, BigQuery removed much of the operational burden, and engineers finally gained the freedom to preserve virtually everything.

It was one of the greatest advances in modern analytics.

It also introduced a new habit.

Nobody wanted to delete anything.

The company at the center of this case had spent almost five years building what many executives proudly described as a “single source of truth.” Hundreds of ingestion pipelines continuously imported information from transactional databases, CRM systems, Google Analytics 4, AppsFlyer, payment providers, customer support platforms, advertising networks, and dozens of third-party APIs. Every new business initiative seemed to produce another dataset, another scheduled pipeline, and another collection of historical records.

The platform kept growing.

So did the monthly invoice.

Initially, nobody paid much attention. Compared to engineering salaries or marketing budgets, cloud storage represented a relatively small percentage of operating expenses. Even when the amount of stored data doubled, the increase appeared reasonable. More customers generated more events, and more events naturally required more storage.

The assumption remained unchallenged for years.

Until a FinOps review introduced a surprisingly simple metric.

Percentage of data accessed during the previous twelve months.

The engineering team expected the answer to be comfortably above seventy percent.

After all, why would anyone continue storing information that nobody used?

The actual number shocked everyone.

Only 18 percent of the stored datasets had been accessed during the previous year.

At first, several engineers questioned the methodology.

Perhaps archival systems were excluded.

Perhaps scheduled jobs had not been counted.

Perhaps access logs were incomplete.

The FinOps analysts repeated the measurements using BigQuery audit logs, INFORMATION_SCHEMA metadata, and Cloud Billing exports.

The result barely changed.

More than four-fifths of the analytical platform had effectively become a digital warehouse of forgotten information.

The discovery immediately created tension.

Deleting data is one of the most politically sensitive decisions inside any technology organization.

The marketing department insisted historical campaigns might eventually require long-term comparison.

Risk managers reminded everyone that historical customer behavior could become valuable for future fraud models.

Data scientists argued that machine learning projects often benefit from additional history.

Compliance teams raised concerns about accidental removal of regulated information.

Every department had perfectly reasonable arguments.

Collectively, those arguments produced a simple policy.

Delete nothing.

The CTO listened carefully before asking a question that nobody had expected.

“Can anyone identify one business decision made during the last two years that required data nobody had accessed during the last twelve months?”

Silence.

Not because the question was unfair.

Because nobody could answer it.

That moment exposed a phenomenon that exists in almost every mature data platform.

Organizations rarely store information because it has demonstrated future value.

They store it because someone once imagined it might have future value.

Those two statements sound similar.

Financially, they are worlds apart.

The engineering team decided to investigate further.

Instead of measuring how much data existed, they started measuring something considerably more important.

How much of that data continued creating business value?

The answer would force the company to challenge one of its oldest engineering beliefs.

More data is not always a better asset.

Sometimes it is simply a larger liability.

The Most Valuable Table Was the One That No Longer Existed

The investigation that followed was unlike any technical audit the company had conducted before. Nobody was searching for failing pipelines, inefficient SQL, or underperforming infrastructure. Instead, the engineering team was trying to answer a surprisingly uncomfortable question.

If a dataset disappeared tomorrow, who would actually notice?

It sounded almost heretical.

For years, engineers had been rewarded for preserving information. Data loss was considered one of the greatest operational risks, and for good reason. Storage was inexpensive, business requirements changed constantly, and historical data occasionally became invaluable during audits or strategic analysis. Keeping everything felt like the safest possible decision.

What nobody had measured was the cost of that philosophy.

The team built a simple inventory of every BigQuery dataset in the platform. For each table they collected six attributes: storage size, monthly storage cost, query frequency, last access date, downstream dependencies, and business owner. The exercise appeared administrative at first, but after several days it revealed something the company had never documented.

Nearly 40 percent of all datasets had no identifiable owner.

Some had been created by engineers who had already left the company. Others belonged to projects completed years earlier. Several originated from proof-of-concept initiatives that had quietly evolved into permanent production datasets simply because nobody had ever removed them. Their pipelines still executed every night. Their tables continued growing. Their costs accumulated month after month.

One table attracted immediate attention.

It occupied almost 47 terabytes of storage and had existed for more than four years. Every day, scheduled jobs appended millions of new records to it. At first glance, deleting it seemed unthinkable.

The engineering team traced every dependency.

No dashboards referenced it.

No machine learning models consumed it.

No scheduled reports queried it.

No APIs depended on it.

The last recorded query had been executed nineteen months earlier.

Nobody knew why the ingestion pipeline was still running.

The obvious solution was to delete it immediately.

The CTO refused.

“We are not deleting anything,” he said. “We are going to prove that it is safe to delete.”

That distinction mattered.

Instead of removing the dataset, the team disabled write operations while leaving the table itself untouched. Monitoring alerts were configured to detect failed jobs, missing queries, or unexpected access attempts. They waited for two weeks.

Nothing happened.

No incident tickets appeared.

No business users complained.

No dashboards failed.

No product owner contacted the data team.

The largest dataset in the platform had effectively disappeared from daily operations without anyone noticing.

That result changed the philosophy of the entire organization.

Rather than asking, “Can we delete this?”, engineers began asking, “What evidence justifies keeping it?”

The review expanded rapidly.

Historical staging tables were removed after verifying that transformed data already existed elsewhere. Intermediate datasets produced by Dataform were regenerated on demand instead of being stored indefinitely. Duplicate exports created for projects that had long since ended were archived to low-cost Cloud Storage rather than occupying premium analytical storage. Temporary development datasets received automatic expiration policies so that abandoned experiments would quietly disappear instead of becoming permanent infrastructure.

The biggest savings, however, did not come from storage.

They came from computation.

Several scheduled pipelines were discovered to be processing obsolete datasets every night simply because those datasets still existed. Eliminating unnecessary tables automatically eliminated dozens of transformations, validation jobs, quality checks, and incremental merges. BigQuery stopped processing data that no longer served a business purpose. Cloud Run jobs disappeared. Scheduler executions were removed. Even monitoring dashboards became simpler because there were fewer systems to observe.

The platform had not only become cheaper.

It had become easier to understand.

Six months after the initiative began, the results were reviewed during the annual technology strategy meeting.

Storage costs had decreased by approximately 32 percent.

BigQuery compute costs fell by nearly 18 percent, largely because unnecessary processing had disappeared alongside obsolete datasets.

More importantly, engineering teams spent significantly less time investigating pipelines whose outputs nobody actually used.

The combined financial impact exceeded $380,000 over the following twelve months.

Ironically, the executives were less impressed by the savings than by another number.

The company had reduced the total number of production datasets by almost 45 percent without losing a single business capability.

One board member summarized the outcome with a smile.

“So we’ve been paying to maintain a museum.”

The room laughed.

The analogy was unexpectedly accurate.

Museums preserve history because history has cultural value.

Data platforms should preserve history because history has business value.

Those are not the same thing.

A mature cloud platform is not measured by how much data it stores. It is measured by how efficiently it converts data into decisions. Every dataset that no longer contributes to that objective increases complexity, consumes engineering attention, and quietly raises operational costs.

Deleting data is often viewed as an act of destruction.

In reality, thoughtful deletion is one of the highest forms of architectural discipline.

It forces organizations to distinguish between assets they genuinely need and liabilities they have simply grown accustomed to carrying.

Executive Takeaways

• Data without ownership inevitably becomes operational debt.
• Cheap storage often hides expensive downstream processing.
• Every production dataset should have an accountable business owner.
• Archive by policy, not by habit.
• The simplest way to reduce cloud costs is often to stop generating unnecessary data.

One Question Every CTO Should Ask

“If we stopped updating this dataset tomorrow, how many business decisions would actually change—and who would be the first person to notice?”

Uncontrolled BigQuery queries, over-provisioned infrastructure, and hidden cloud waste often build up silently as data platforms scale. Rather than cutting resources blindly or imposing rigid limits that stall engineering velocity, effective cost control requires a precise, architectural review of your workload. My FinOps on GCP service is designed to identify query inefficiencies, optimize data partitioning, and align your cloud expenses directly with technical and business value. We focus on finding the root causes of runaway bills—from unoptimized transformations to redundant storage—without compromising system performance. If you are looking for a calm, data-driven approach to make your Google Cloud environment predictable and cost-efficient, I invite you to explore the details.