title: Why do Entity Framework Migrations store the whole model and not a hash in the __MigrationHistory table?
body: <p>Code First Entity Framework, from versions 5 - 6.1.1+, with migrations enabled stores database updates as "migration" classes. Each class has an accompanying resource file containing a serialized version of the model, i.e. the entities, properties, relationships, etc.</p>
  
  <p>This serialized version of the model is then stored in the database in the __MigrationHistory table with a single row per migration. The information in this table is used to check what model version a database is at and thus what migrations still need to be run. It is also used during some database initialization strategies to determine if the running code's model matches the last migration deployed to that database.</p>
  
  <p>In neither of the use cases for the __MigrationHistory table is the fully serialized model needed. At best only a hash of the model would appear to be required.</p>
  
  <p>As we've had our code first database running for a while, the __MigrationHistory table is storing 36K per row for a total of 4MB. This isn't huge but seems unnecessary.</p>
  
  <p>So the question: Why doesn't Entity Framework store a hash of the model in the __MigrationHistory table?</p>