---
title: "How an Intern Released 3 Terabytes Worth of Storage Before BFCM"
description: "While preparing for Black Friday Cyber Monday (BFCM), Shopify’s Products team found that historical reporting records were causing MySQL to scan many InnoDB pages to return a single record. An intern built a Rails background job to delete the records safely, using Shopify’s job-iteration library to process small batches and an internal throttling enumerator to pause when database health or replication lag became a concern. Indexed fetch queries and cursor-based batching avoided repeated scans and timeouts, while the iterator deleted each batch. Run about two weeks before BFCM, the job deleted more than 5 billion records, peaked at approximately six million records per minute, and released three terabytes of storage. Afterward, the database scanned around three times fewer pages per returned record, improving resilience to flash-sale traffic and producing large cost savings."
---

# How an Intern Released 3 Terabytes Worth of Storage Before BFCM

[Shopify](https://yomu.fyi/company/shopify) · Gurpreet Gill · Dec 14, 2018

**Type:** Problem & solution

## Summary

While preparing for Black Friday Cyber Monday (BFCM), Shopify’s Products team found that historical reporting records were causing MySQL to scan many InnoDB pages to return a single record. An intern built a Rails background job to delete the records safely, using Shopify’s job-iteration library to process small batches and an internal throttling enumerator to pause when database health or replication lag became a concern. Indexed fetch queries and cursor-based batching avoided repeated scans and timeouts, while the iterator deleted each batch. Run about two weeks before BFCM, the job deleted more than 5 billion records, peaked at approximately six million records per minute, and released three terabytes of storage. Afterward, the database scanned around three times fewer pages per returned record, improving resilience to flash-sale traffic and producing large cost savings.

## Context

During BFCM preparations, the team analyzed its top SQL queries and found that records retained for historical reporting were causing excessive InnoDB page scans. The records were reviewed with other teams and approved for deletion because the database needed to remain resilient under increased flash-sale traffic.

## Approach / What changed

The Rails background job used job-iteration to enumerate records in small batches and pass each batch to an iterator for deletion. An internal throttling enumerator paused processing when the database showed signs of overload, while indexed fetch queries and a cursor for batch progression helped avoid timeouts and repeated scans.

## Takeaways

- The deletion job removed more than 5 billion records, released three terabytes of storage, and reached approximately six million records per minute at its peak.
- Small batches and pauses between iterations limited the impact of deletion operations, while throttling automatically stopped the job when the database was not healthy.
- After deletion, the database scanned around three times fewer pages to return a single record, allowing it to serve more flash-sale requests without unnecessary page scans.

## FAQ

### How did the job prevent deletion from overloading the database?

It processed records in small chunks rather than issuing one large deletion. An internal throttling enumerator checked the database after each iteration and paused the job when it detected overload or a need to protect database availability.

### Why did the job use a cursor for batch processing?

The cursor flagged the last record in the previous batch and used it as the pivot for fetching the next batch. This avoided re-fetching earlier records and helped prevent query timeouts.

### What changed after the records were deleted?

The job freed three terabytes of storage and deleted more than 5 billion records. The database scanned around three times fewer pages per returned record, making it more resilient during flash sales and resulting in large cost savings.

**Tags:** [MySQL](https://yomu.fyi/topic/mysql), [Performance](https://yomu.fyi/topic/performance), [Ruby on Rails](https://yomu.fyi/topic/ruby-on-rails), [Scalability](https://yomu.fyi/topic/scalability)

- Source: [Shopify](https://shopify.engineering/how-an-intern-released-3-terabytes-worth-of-storage-before-bfcm)
- Source URL: https://shopify.engineering/how-an-intern-released-3-terabytes-worth-of-storage-before-bfcm
- Ingested by Yomu: 2026-09-17T14:06:25.453Z

[Read original post](https://shopify.engineering/how-an-intern-released-3-terabytes-worth-of-storage-before-bfcm)