Some database buckets are mandatory for successful sync and block processing. For example, AT (current state of accounts), ST (current state of contract storage), SUFFIX (changesets used for rewinding). Other buckets are optional and only add value for certain users. We would like users to have flexibility to pick and choose those buckets in any combination. Users may specify the mode of operation as a combination of one-letter flags (similar to unix tar command). Here are suggested flags:

1. r Transaction receipts. Currently turned off by default. If turned on, receipts are written to a special bucket, which is then used to server getTransactionReceipt and getLogs RPC commands. In blockchain.go this is set by EnableReceipts(true)
2. h History of state. These are buckets hAT (history of state of accounts) and hST (history of state of contract storage). Although these buckets contain the same information as the SUFFIX (change-set) bucket, it is organised for quick access using addressHash | blockNr composite key for accounts, and addressHash | incarnation | blockNr composite key for contract storage. Bucket SUFFIX is organised for quick access for composite keys "hAT" | blockNr and "hST" | blockNr. History of state is used for answering various RPC queries related to account balances, contract storage contents at some point in the past.
3. t Index allowing to look up block number and transaction index given a transaction hash. It is used by RPC requests such as getTransaction, because it allows retrieving the body of the transaction from the bucket with blocks
4. p preimages for address hashes and storage key hashes. This information is needed by RPC queries such as getModifiedAccounts and getStorageRangeAt.
5. Block headers and bodies? In order to perform reorgs, some short history of alternative blocks and headers is required.

Some examples of which modes might be useful for different use-cases:

• Miners would prefer to turn all the flags off, they only care about the current state and occasional reorgs. Their priority - low latency of block processing, and lowering I/O would definitely help
• Exchanges would need preimages (p) and history (h) to be able to watch for deposits. If they use logs (events) to figure out token transfers, they might also want to turn on receipts (r) for better performance
• Block explorers might want to turn everything on
• Dapp Web sites would want to turn on receipts (r) for better scanning of the logs (lots of dapp use logs as a substitute for storage).