SQL change management has always sucked. This talk introduces Sqitch, the VCS-aware SQL change management application that doesn't suck. Come see how it works, learn the few simple rules you need to get the most out of it, and liberate yourself from the suckitude. SQL change management is hard. Most "migration"-style implementations require opaque naming conventions, prefer DSLs that cover a fraction of SQL, and require duplication of code for simple changes to existing functions. Such does not have to be. And now it's not Introducing Sqitch, simple SQL change management that doesn't suck. Sqitch doesn't care what programming language your app is written in. It has no opinions as to what database to use or what its schema should look like. And it doesn't require sequentially-named migration scripts or the use of any DSL other than SQL. Sqitch lets you to write SQL migration scripts thar target your database, and provides a simple, unintrusive interface for specifying dependencies, so that it can run things in the proper order. Best of all, when used with a version control system (initially Git), you can even modify idempotent deployment scripts between releases. Sqitch recognizes such changes, and automatically knows how to revert to earlier versions if required. And finally, Sqitch supports simple acceptance testing, so that you can be sure that your deployments are successful, and, if not, revert them. So come to this talk to learn all about Sqitch: How it works, where to get it, and how to get the most out of managing database deployments.