Hi @influencebydesign,
This depends greatly on the type of site you have and if/how other people will be working on this site.
As a basic setup, I’d suggest a dev environment on your local computer, a staging environment that keeps fresh with master, and of course production.
On dev you shouldn’t really be tracking the database at all, instead just pulling down a fresh copy of the db from master every once in a while.
If you’re working with other developers, staging should also keep a fresh copy of the DB from master, and changes from dev should obviously be tested on staging before pushing live.
How much of the DB you’re tracking is what highly depends on the site. For smaller sites that don’t get a ton of comments, new posts, etc. you can track the entire database and not really worry about anything.
If it’s a much larger site, with lots of activity, you’ll need to either track only the most important DB tables and/or make sure that you are pulling DB changes from master more often before deploying so you don’t overwrite DB content. In this sense it helps to think of it in the same way you would think of a standard database migration/go-live process.
More information is being updated to the docs, but feel free to reach out with any questions. Thanks!
