> Why? If you want it at some place, you request it. Or you request it with '*' most of the time anyway.

But there's no *principle* that determines what information is kept in the schema and what is in the payload. Right now it's an ad hoc decision based on appeals to "common sense" and "intuition." But we're laying the foundation for hopefully the next five years or more of Gittip's growth, and what seems common sense and intuitive to us now is not a good enough criterion for elevating some pieces of information to the `events` schema level.

The four reasons offered above for including something in the schema instead of the payload are:

 - Schema fields can be required.
 - Schema fields are strongly typed.
 - Schema fields can have default values.
 - Ease of filtering.

Basically, what's dawning on me is that our decision to go with this event sourcing architecture moves us into the realm of schemaless data storage as well. NoSQL. The name of the game with a schemaless data store is enforcing our schema at the application layer. Ultimately, there's no way around that for us if we're going to use this pattern. And if we have to do application-layer schema enforcement for the payload anyway (and we do), then why have certain bits of our schema still enforced by PostgreSQL instead of at the application layer?

I think we should think of the `events` table as something quite low level&mdash;just `id` and `payload`&mdash;and we should expect to be writing significant abstractions atop it for day-to-day use.