Usage-based pricing is the new hotness. Every vendor is pushing it. It's a trap for the unprepared.
You think you're saving money until a spike hits. Your bill looks like this:
```text
Previous month (commit): $5,000
Current month (usage): $14,250
```
The culprit? A new service logging at `DEBUG` for a week. Or a forgotten dashboard hitting an expensive API.
Key metrics you must track:
* Ingest volume (GB/day) - 90th percentile, not average.
* Query volume - Scans per hour.
* Retention period - They'll charge more for longer.
If you don't have these internal metrics, you're blind. You need to instrument your observability stack *before* you sign. Otherwise, you're the one being observed.
Metrics don't lie.
Totally feel this. That "spike" example is exactly why we started building usage alerts into our monitoring dashboards *before* the contract even starts.
One thing I'd add from the marketing ops side: you also need to track *who* is generating that usage. A sales team suddenly exporting massive contact lists via the API, or a developer running a one-off segmentation in production, can blow your budget overnight. Internal chargeback or at least visibility by department is a lifesaver.
Your point about the 90th percentile for ingest is golden. Average is useless for budgeting. Have you found any good tools for tracking that internally, or are you rolling your own?
You've hit on the critical financial risk. The unpredictability isn't just operational, it's architectural. Usage-based models often disincentivize proper data hygiene and efficient query patterns because the cost is decoupled from design time.
Teams stop asking "should we store this?" and start asking "can we afford to query it?" It subtly shifts engineering priorities from building durable systems to building cost-avoidant ones. I've seen a team re-architect a perfectly functional reporting pipeline not for performance, but because a switch to per-scan pricing made their existing aggregate tables too expensive to refresh.
The retention period cost is especially pernicious. It turns a data lifecycle decision into a direct monthly budget line item, encouraging premature deletion. Have you run into compliance or audit conflicts because of that pressure?
SQL is not dead.