Currently, bqschemaupdater is run manually. Because of this, there are a few problems:
* The schema that is saved in version control might not necessarily match the schema of the actual table. 
* There is no requirement that a schema is code reviewed before a table is created from it.
* bqschemaupdater must be run manually.

If we wrote a tool to automate bqschemaupdater, we should consider the following:
* The tool needs to know the path to the proto file and the ids of the associated project, dataset, and table. We could add configuration with that information for each table definition.
* The tool needs to authenticate itself for the given project. Maybe we’d use a single service account, and projects would need to give that service account permission to insert and update tables.
* Disabling running the tool manually.  
* Monitoring for table inserts/updates, with alerting as we approach or exceed limits.