18 Months of Events Fit on Four Floppy Disks¶
"Event Sourcing uses too much storage." We hear this all the time. The argument goes like this: since you never delete anything and only append new events, your storage requirements grow indefinitely. Eventually, you'll run out of space. It sounds logical. It's also almost always wrong.
The append-only nature of Event Sourcing is real. But the conclusion that this leads to storage problems is based on three fundamental misconceptions that we see over and over again. Let's examine them, and then look at real production data that might surprise you.
The Three Big Misconceptions¶
People overestimate how many events they actually have. When developers think about Event Sourcing, they often imagine millions of events flooding their system every day. But most business applications don't generate that kind of volume. A typical e-commerce order might produce five to ten events: OrderPlaced, PaymentReceived, OrderConfirmed, ItemShipped, OrderDelivered. That's it. Even a busy online shop with 1,000 orders per day generates only 5,000 to 10,000 events daily. That's not a flood. That's a trickle.
People overestimate how large a single event is. Events are not database rows with dozens of columns. They're not JSON documents with megabytes of nested data. A well-designed event captures a single fact: what happened, when, and the minimal context needed to understand it. Most events are measured in hundreds of bytes, not kilobytes. An OrderPlaced event might contain an order ID, a customer ID, a timestamp, and a list of product IDs with quantities. That's typically 200 to 500 bytes. Not 20 KB. Not 200 KB.
People underestimate how much storage 1 TB actually provides. One terabyte sounds abstract until you do the math. If your average event is 500 bytes, one terabyte holds two billion events. If you generate 10,000 events per day, that's 200,000 years of storage. Even at 100,000 events per day (which would be a very busy system), you're looking at 20,000 years. The numbers simply don't support the "storage explosion" narrative.
A Real-World Test: Our Todo App¶
Theory is nice, but let's look at actual production data.
At the native web GmbH, we've been running an internal todo application since April 30th, 2024. It's not a demo. It's the tool we use every day to manage our work: tasks, reminders, grocery lists, appointments, and everything else that needs tracking. Multiple team members, real usage, real data.
As of today, after more than 18 months of continuous use, the application contains exactly 8,610 events. The Merkle root (a cryptographic fingerprint proving we haven't manipulated the data) is:
Now, before we reveal the storage size, let's play a guessing game. How much disk space do you think 8,610 events from 18 months of daily use require?
- 1 MB?
- 5 MB?
- 10 MB?
- 25 MB?
- 50 MB?
- 100 MB?
Take a moment. Pick a number.
The Reveal¶
The answer: 5 MB. (If you knew that because you remembered the title: kudos for paying attention.)
Eighteen months of work. 1,683 todos remembered, adjusted, postponed, and completed. All of it fits into 5 MB.
To put this into perspective: a single 3.5-inch floppy disk from the 1990s held 1.44 MB. Our entire event history, uncompressed, would fit on four floppy disks. Four. That's the "storage explosion" people worry about.
Let's extrapolate. If we continue at this rate, how long until we fill a 1 TB drive? At roughly 3.3 MB per year, we'd need about 300,000 years. We're not particularly worried.
Storage is Cheap (and Plentiful)¶
But here's the thing: even if your use case generates significantly more events than our todo app, storage is simply not a meaningful constraint anymore.
Consider this: the MacBook Pro this blog post is being written on is from 2022. It's almost four years old. It has 1 TB of storage. That's not a high-end server in a data center. That's not specialized enterprise hardware. That's a laptop you could buy at any electronics store years ago.
Cloud storage is even cheaper. As of 2025, storing one terabyte on AWS S3 costs around 21 EUR per month. Azure Blob Storage and Google Cloud Storage offer similar pricing. For the cost of a few cups of coffee, you get more storage than most event-sourced applications will ever need.
And here's the practical reality: if you ever do run low on storage, you just add more. This isn't the 1990s where expanding storage meant buying new hardware, scheduling downtime, and migrating data. Today, you click a button or change a configuration value. Cloud providers will happily sell you as much storage as you want. Self-hosted solutions can expand storage pools dynamically. It's a solved problem.
The only exception might be embedded systems or highly constrained IoT devices where every kilobyte counts. But if you're building an event-sourced system for embedded hardware, you probably already know your constraints and have planned accordingly.
Do the Math Yourself¶
Still skeptical? We've built a calculator specifically for this purpose.
Visit the EventSourcingDB storage calculator. You can:
- Enter a typical event payload from your domain
- Specify how many events you expect (per second, minute, hour, or day)
- Choose a time horizon (one month, one year, ten years)
The calculator computes the actual storage requirements based on real event sizes. It also factors in the overhead from indexes and internal data structures that EventSourcingDB uses. No guessing, no hand-waving. Just math.
For most projects, the results are eye-opening. What seemed like a potential problem turns into a non-issue when you look at actual numbers instead of vague assumptions.
The Real Questions¶
In a recent blog post, we discussed that Event Sourcing is not for everyone (or rather: not for everything). The decision of whether to use Event Sourcing should be based on whether your domain benefits from capturing the full history of changes, whether you need audit trails and traceability, and whether understanding "how you got here" matters as much as "where you are now."
Storage should almost never be part of that decision. It's a distraction. A red herring. A problem that sounds plausible but rarely materializes in practice.
The real questions are: Do you need to understand the history of your data? Do compliance requirements demand an audit trail? Would replaying events to debug issues or analyze behavior be valuable? Can your domain be modeled as a sequence of facts?
If the answers are yes, Event Sourcing is worth considering. And storage? Storage will take care of itself.
Conclusion¶
The "Event Sourcing storage problem" is largely a myth. It persists because it sounds reasonable and because people rarely do the actual math. But when you look at real data (like our todo app with 18 months of events fitting on four floppy disks), the narrative falls apart.
Events are small. Most applications generate fewer events than people imagine. And storage is cheap, plentiful, and easy to expand.
Don't let phantom storage concerns stop you from choosing the right architecture for your domain. Do the math. Look at your actual event sizes and volumes. Use the calculator if it helps.
And if you're ready to try Event Sourcing without worrying about storage, the Getting Started guide will walk you through your first steps with EventSourcingDB.
The future might be append-only. But it's not as big as you think.