Beyond Index‑Only: Building Tiered Observability with CtrlB
Sep 3, 2025

What’s Wrong With the Old Way of Logging?
For years, the default way to handle logs has been simple: collect everything, index everything, and hope your search engine can keep up. This “index-only” mindset made sense when log volumes were small. But today’s systems generate terabytes daily, and indexing all of that data has become painfully expensive. Teams end up forced into trade-offs: keep only a short window of logs, sample aggressively, or drop valuable context altogether. The result? Blind spots when you need answers the most.
Why Think About Tiers Instead of One-Size-Fits-All?
Not all logs are created equal. Some are vital in the moment (like errors during an outage), while others matter weeks or months later (like security audits). Treating both the same is wasteful. Tiered observability takes a layered approach:
- Hot data stays close for fast troubleshooting.
- Cold data sits in cheaper long-term storage but remains accessible when needed.
This way, you avoid paying premium prices to index every single log while still keeping the full history intact. It’s about control and flexibility, storing data based on how you’ll actually use it.
How Do Engineers Benefit From Tiered Observability?
Think of a developer on-call at 2 a.m. If an outage happens, they don’t need to sift through six months of logs; they need the last hour. That’s the hot tier. Now, picture the compliance officer three months later who needs to pull login activity for a security review. That’s the cold tier.
Both jobs rely on logs, but their needs are different. Tiered observability makes sure each gets the right balance of speed and cost. Engineers debug quickly without draining budgets, and compliance teams know historic data will be there when asked.
Where Does CtrlB Fit In?
CtrlB was built around this idea from the start. Instead of running heavy clusters that index everything 24/7, CtrlB:
- Stores all logs in object storage like S3 (cheap and durable).
- Uses on-demand compute to query data only when you ask.
- Keeps lightweight indexes for fast filtering, so even big queries feel interactive.
This design flips the script: you don’t pay for endless indexing you rarely use. You pay when you run a query. That means teams can afford to keep full-fidelity logs for months or years, not just days.
What Does This Look Like in Practice?
Here are two fresh scenarios that highlight the difference:
- A startup is scaling fast. Traffic doubles overnight after a product launch. Traditional logging would mean spiraling costs just to keep new data searchable. With CtrlB, they continue collecting everything without fear, knowing yesterday’s surge won’t blow up next month’s bill.
- A bank preparing for an audit. Regulators request six months of login activity. Instead of digging through tapes or rehydrating archives, the compliance team runs a query in CtrlB directly against cold storage. The logs are still there, still intact, and ready in minutes.
In both cases, tiered observability isn’t about saving pennies; it’s about trusting that the data you need is always there without stressing about cost.
Why Does This Matter for the Future of Observability?
Systems are only getting bigger, noisier, and harder to manage. Observability that relies on indexing everything upfront won’t scale forever. Tiered models like CtrlB’s give teams room to grow. They let you:
- Keep more history without cutting corners.
- Control which logs are fast vs. slow without losing them.
- Stay audit- and compliance-ready at all times.
This shift is bigger than storage. It’s about giving engineers and businesses confidence that they can see what’s happening in their systems now and later without compromise.
FAQ: Tiered Observability and CtrlB
Q1. Is tiered observability only about saving money?
No. It’s also about coverage. Teams don’t have to drop logs or shorten retention. You keep the full picture and decide when you need speed vs. when you just need history.
Q2. Does storing logs on S3 make searches slow?
Not with CtrlB. Queries spin up compute on demand and use smart micro-indexing. That means you still get interactive results, even from huge datasets.
Q3. Can I use CtrlB for both debugging and compliance?
Yes. Hot logs are great for developers troubleshooting issues. Cold logs give compliance and security teams the history they need for audits or investigations.
Q4. How is CtrlB different from “archive and rehydrate” solutions?
With CtrlB, you don’t have to restore data into a cluster to query it. Logs are always queryable where they live. That cuts out delays and complexity.
Q5. Who benefits most from this approach?
Engineering teams tired of log limits, compliance-heavy industries (finance, healthcare), and fast-scaling startups that can’t afford runaway observability costs.