Problems surfacing with the db migrations because matviews cannot be modified, they must be recreated. A migration then involves deleting the old, and fully recreating the new with modifications. This is difficult to review and see changes, but more so a problem for parallel work streams. If two PRs modify the same view, each will not contain the changes from the other, last merge will win and the changes from the previous will be lost.

We may want to consider managing these in-code when sippy starts. Store the matviews in code variables, apply them, and store a hash of the definition we applied. If we startup and see a new hash differ from the last we stored, delete the matview, recreate, and update the hash.