Predicting storage growth: A simple framework

Storage growth is rarely dramatic. It creeps: a new logging feature here, a media upload option there, and a version toggle flipped during a sprint and never revisited. Individually, they're harmless. Collectively, they're expensive. This post is a simple framework for predicting storage growth before it becomes a surprise. There's no heavy math and no finance jargon—just practical thinking that teams can build into their planning and decision-making skill set.

Why storage forecasting is a skill worth learning 

Infrastructure planning is often treated like someone else’s job, but the reality is that storage growth is driven by product decisions. If you ship features, you shape storage curves whether you intend to or not.

Teams that learn to model storage early tend to:

• Avoid emergency cleanups.

• Design smarter retention rules.

• Make better roadmap trade-offs.

• Be prepared in budget reviews.

Think of it as product sense but for infrastructure.

Step 1: Start with a simple growth model 

You don't need a complex spreadsheet to get started—you just need three numbers:

1. Number of objects created each month
This is how many individual files or stored items your system generates in a month. It reflects user activity, feature behavior, and any automated processes creating data behind the scenes.

2. Average size of each object
This is the typical storage footprint of each file you store. Even small increases here can significantly impact overall growth because every object carries that size multiplier.

3. Retention duration
This is how long each object remains stored before being deleted or archived. The longer data stays, the more monthly uploads accumulate into your total storage footprint.

A basic formula looks like this:

Monthly storage growth = objects per month × average object size × retention duration

That’s it.

If your app creates one million objects a month, each around 500 KB, and keeps them forever, you're adding roughly 500 GB every month.

This simple model is usually enough to spot trouble early.

Step 2: Estimating average object size (without guessing) 

Average object size is where teams often shrug and move on, but you can usually get close with a little observation.

Look at real data 

Check a representative sample of objects:

• Images uploaded by users

• Log files generated per service

• Backups produced per job

You don't need perfection; you just need a believable range.

Segment by object type 

Most storage systems don't just store one kind of data.

For example:

• User images: 2 to 5 MB

• Thumbnails: 50 to 100 KB

• Logs: 5 to 20 KB per object

• Exports: 10 to 50 MB

Model them separately, and add them together later.

Plan for growth

Features evolve. Image quality improves. Logs get more verbose. Export formats change.

A safe habit is to model both the current average size and the expected size in 6 to 12 months.

Step 3: Understand feature impact on storage over time 

This is where product thinking really matters. Not all features grow storage in the same way.

Features that create new objects 

User uploads, event logs, analytics snapshots, and media processing outputs are all features that create new objects. They add storage linearly or exponentially, depending on usage growth.

Ask:

• Does every user action create data?

• Does usage scale with users, sessions, or time?

Features that multiply storage 

Some features quietly double or triple usage.

Common contributors include object versioning, backups of already stored data, and derived assets like previews and transcodings.

One change can alter your growth curve entirely.

Features that retain data longer than intended 

Retention is often an afterthought.

Examples:

• Logs kept “just in case”

• Old versions that are never cleaned up

• Customer data that hasn't been accessed for the past six months

If data never expires, growth never stops. This is where being intentional about what data is kept and for how long becomes a critical guardrail for sustainable systems.

Step 4: Model time, not just size 

Storage problems rarely appear in month one. They show up in a few months of usage.

When forecasting, ask:

• What does this look like after three months?

• After a year?

• After a major feature launch?

Thinking about storage growth over time helps teams anticipate when usage may accelerate. That mental model alone can influence decisions, encouraging earlier discussions around retention and more thoughtful feature trade-offs.

Step 5: Turn forecasting into a team habit 

The goal is not a perfect prediction; it’s awareness.

A simple practice that works well:

• Add a storage impact note to feature specs.

• Review storage assumptions during planning.

• Revisit forecasts after major launches.

Over time, teams build intuition, and storage stops being a surprise and becomes part of deliberate planning.

The takeaway

Storage rarely kills a product overnight. It kills margins silently. That’s why storage growth isn’t really an infrastructure problem; it’s a product behavior problem. Every feature influences how data is created, reused, and retained, whether teams plan for it or not.

Teams that learn to predict this behavior don’t just save money; they design cleaner systems, make more intentional product decisions, and avoid uncomfortable surprises as usage scales.

Start storing with Catalyst Stratus, Happy storing!