Describe a scenario where you would use a Big Object, and what you would give up by choosing it.

A concrete example: a utilities client capturing smart-meter readings at fifteen-minute intervals for two million meters. That is billions of rows, immutable, and analysed in bulk.

1. Why Big Object fits: It handles that volume, it does not consume standard data storage, and the access pattern — retrieve by meter and time range — maps cleanly onto a predefined composite index.
2. What you give up: No roll-up summary fields, no validation rules, no standard sharing model, limited trigger support, and querying is constrained to the index you defined at creation — which you cannot casually change later.
3. How I compensate: Async SOQL aggregates the readings into a small custom object holding daily and monthly summaries. Users report on that object with ordinary reports and dashboards and never touch the Big Object directly.
4. The design risk: The index is the whole design. If you get the composite key wrong, the object is effectively unqueryable for the access patterns you need, and the remedy is creating a new object and reloading. I spend disproportionate time on that decision.