Explain the difference between skinny tables, custom indexes, and Big Objects, and when you would use each.

They solve different problems and are not interchangeable:

1. Custom index: Added by Salesforce Support on a field the optimiser would otherwise scan. It only helps if the filter is selective — an index on a two-value checkbox is wasted effort. This is the first thing I try because it is cheap and reversible.
2. Skinny table: A Salesforce-maintained copy of a narrow, frequently used subset of an object's fields (up to 100), which removes the join between the base table and the custom-field table. Good for a report or list view that is run constantly over the same handful of columns on a very large object. Caveat: skinny tables do not automatically carry to a sandbox or a new org and must be re-requested, so I record them in the deployment runbook.
3. Big Object: A different storage tier entirely, for hundreds of millions of immutable rows queried by a predefined index. It does not consume standard data storage. I use it for archives and event history, and I query it with Async SOQL, writing aggregates into a small custom object that users can report on normally.
4. Sequencing: In practice I work in that order: make the query selective, then index, then skinny table, and only reach for Big Objects when the real answer is that the data should not be sitting in a transactional object at all.