The Quarry and the River: On the Economics of Data Collection

A question I find myself returning to is one many of you might have pondered during a late-night log review: how much is too much? Not in the sense of cost, but in sheer volume. We build these intricate systems to collect everything—every request, every error, every subtle dip in performance. We act like quarry owners, convinced that the mountain itself is the asset. We extract, we stockpile, we build ever-larger silos for our digital stone, believing that one day we’ll carve a masterpiece from it. But a quarry is a static, heavy thing. The real value isn't in the mountain; it's in the flow.

This hit home for me while debugging a memory leak in a small, stubborn service. The metrics were noisy, a constant stream that made it difficult to spot the anomalous trickle that was the real problem. I had spent weeks instrumenting this service, proud of the granularity I’d achieved. But in that moment, the sheer mass of data was the problem. It was costing me—not in storage fees, but in attention. My quarry was so full of rock I couldn't find the specific flawed stone. It struck me that our approach to observability often lacks an economic model beyond storage cost. We don't account for the cognitive overhead, the cost of sorting signal from noise.

Building Dams and Canals

This is where the metaphor of the river begins to feel more useful. Instead of treating data as an inert resource to be mined, what if we treated it as water? A river is a system of flow. It has a source, and it has a destination. The art is in managing that flow. We build dams not to stop the water, but to control its release and harness its energy. We dig canals to direct it to where it's most needed. This is the practice of data triage: defining at the source what is critical, what is merely informational, and what is ephemeral runoff.

For my leaky service, the solution wasn't more logging. It was better filtering. I built a ‘dam’ at the source—a configuration that elevated the severity of memory-related events and suppressed the chatter of normal operation during the investigation. It was a temporary, purposeful constriction of the flow to highlight a specific problem. The data itself remained a river, but I was now building canals to guide my attention. This is a fundamentally different posture: not one of ownership over a static pile, but one of stewardship over a dynamic stream.

The goal, then, is not to fill the quarry. The goal is to understand the watershed. It’s to know which data streams are vital arteries and which are minor capillaries. It's to design systems where data flows with purpose, not just accumulates by default. The most reliable operations are often the simplest, not because they collect less, but because they collect smarter. They respect the economics of attention, understanding that the true cost of a log line isn't the disk space it occupies, but the time it takes a human to consider it. Before you add another metric, ask yourself: are you building a bigger quarry, or are you learning to navigate the river?

Notes & further reading

A few pages I came back to while writing this: