What is the Data Contract pattern, and why does separating data from logic make upgrades cheaper?

Store an application's data in its own dedicated smart contract, separate from the logic contracts — so you can redeploy upgraded logic without the expensive job of copying all the data into a new contract.

• Problem. On-chain storage and computation per transaction are limited, so upgrading a contract that holds both logic and data forces you to copy the data from old to new — potentially across multiple transactions when a block's gas limit blocks one big migration. That is slow and, on a public chain, costly.
• Solution. Isolate the data store from the code by keeping data in separate contracts. A generic, flexible structure — for example a mapping from a SHA3 key to a value — is unlikely to need changes, so all the logic contracts can share it. Where the shape is stable and known, a stricter, smaller-footprint structure can be used instead.
• Benefits. Upgradability (replace logic without touching data), cost (no data migration during an upgrade), and generality (one clean data contract serves many logic contracts).
• Drawback. Cost/awkwardness of generality — a generic structure (e.g. one that must store the key) uses more space and is less straightforward to query than a strictly typed one.