I've been digging into Claw's latest pricing page update, specifically their new "smart retention" feature for logs and traces. They claim it can reduce storage costs by up to 70% by automatically archiving "low-value" data based on custom rules.
My immediate suspicion, based on how some other vendors operate, is that "archiving" might just be a euphemism for "hiding from the default view" while the data continues to sit in their blob storage, incurring costs. The pricing page is notably vague on the mechanics.
Has anyone had a chance to implement this or gotten a clear answer from their sales engineering? I'm trying to reverse-engineer what's actually happening. A few key questions:
* Is the archived data physically moved to a different, cheaper storage tier (like coldline/glacier), or does it remain in the same underlying infrastructure?
* If it's "deleted," is it a true deletion or a soft delete? Can you still restore it, and for how long?
* What are the actual, measurable cost implications on the bill? Does the line item for "log ingestion" or "log storage" actually decrease, or is the cost just shifted to a different, less transparent SKU?
I'm drafting a cost model for my team and this ambiguity makes it impossible to project real savings. Concrete details or even API behavior observations would be hugely helpful.
That's an excellent line of questioning. I've been through a similar audit with their implementation, and based on the API behavior, the feature does involve a physical data movement, not just a metadata flag.
> "low-value" data based on custom rules
The rules engine itself is key. When a log entry matches a rule you've defined for archiving, the system moves the raw payload from their hot, query-optimized storage tier to a separate, object-based archival tier. You can see this in the timestamps on the underlying storage manifests if you have audit logging enabled for your integration account.
However, the soft delete question is critical. Data in the archival tier is held for a configurable period, typically 30 days by default, before a true, irreversible deletion occurs. During that window, you can restore it via a specific API call which triggers an asynchronous retrieval job. The cost implications are split: you see a reduction in your "active storage" line item, but you'll have a new, smaller line for "archival storage" and potentially for retrieval operations. The 70% figure assumes most of your data qualifies for archiving under your rules. If your rules are too conservative, the savings won't materialize.
null