Provided by: sqitch_1.4.1-1_all 
Name
sqitch - Sensible database change management
Synopsis
sqitch <command> [options] [command-options] [args]
Description
Sqitch is a database change management application. It currently supports:
• PostgreSQL <https://postgresql.org/> 8.4+
• YugabyteDB <https://www.yugabyte.com/yugabytedb/> 2.6+
• CockroachDB <https://www.cockroachlabs.com/product/> 21+
• SQLite <https://sqlite.org/> 3.8.6+
• MySQL <https://dev.mysql.com/> 5.1+
• MariaDB <https://mariadb.org> 10.0+
• Oracle <https://www.oracle.com/database/> 10g+,
• Firebird <https://www.firebirdsql.org/> 2.0+
• Vertica <https://www.vertica.com/> 7.2+
• Exasol <https://www.exasol.com/> 6.0+
• Snowflake <https://www.snowflake.net/>
What makes it different from your typical migration-style approaches? A few things:
No opinions
Sqitch is not tied to any framework, ORM, or platform. Rather, it is a standalone change management
system with no opinions about your database engine, application framework, or development
environment.
Native scripting
Changes are implemented as scripts native to your selected database engine. Writing a PostgreSQL
<https://postgresql.org/> application? Write SQL scripts for "psql"
<https://www.postgresql.org/docs/current/static/app-psql.html>. Writing an Oracle
<https://www.oracle.com/us/products/database/>-backed app? Write SQL scripts for SQL*Plus
<https://www.orafaq.com/wiki/SQL*Plus>.
Dependency resolution
Database changes may declare dependencies on other changes -- even on changes from other Sqitch
projects. This ensures proper order of execution, even when you've committed changes to your VCS out-
of-order.
Deployment integrity
Sqitch manages changes and dependencies via a plan file, and employs a Merkle tree
<https://en.wikipedia.org/wiki/Merkle_tree> pattern similar to Git
<https://stackoverflow.com/a/18589734/> and Blockchain <https://medium.com/byzantine-
studio/blockchain-fundamentals-what-is-a-merkle-tree-d44c529391d7> to ensure deployment integrity. As
such, there is no need to number your changes, although you can if you want. Sqitch doesn't much care
how you name your changes.
Iterative Development
Up until you tag and release your project, you can modify your change deployment scripts as often as
you like. They're not locked in just because they've been committed to your VCS. This allows you to
take an iterative approach to developing your database schema. Or, better, you can do test-driven
database development.
Ready to get started? Here's where:
Sqitch Tutorials
Detailed tutorials demonstrating the creation, development, and maintenance of a database with
Sqitch.
• PostgreSQL, YugabyteDB, CockroachDB Tutorial
• SQLite Tutorial
• MySQL Tutorial
• Oracle Tutorial
• Firebird Tutorial
• Vertica Tutorial
• Exasol Tutorial
• Snowflake Tutorial
PDX.pm Presentation <https://speakerdeck.com/theory/sane-database-change-management-with-sqitch>
Slides from "Sane Database Management with Sqitch", presented to the Portland Perl Mongers in
January, 2013.
PDXPUG Presentation <https://vimeo.com/50104469>
Movie of "Sane Database Management with Sqitch", presented to the Portland PostgreSQL Users Group in
September, 2012.
Agile Database Development <https://speakerdeck.com/theory/agile-database-development-2ed>
Three-hour tutorial session on using Git <https://git-scm.org/>, test-driven development with pgTAP
<https://pgtap.org>, and change management with Sqitch.
Terminology
"change"
A named unit of change. A change name must be used in the file names of its deploy and a revert
scripts. It may also be used in a verify script file name.
"tag"
A known deployment state, pointing to a single change, typically corresponding to a release. Think of
it is a version number or VCS revision. A given point in the plan may have any number of tags.
"state"
The current state of the database. This is represented by the most recently-deployed change. If the
state of the database is the same as the most recent change, then it is considered "up-to-date".
"plan"
A list of one or more changes and their dependencies that define the order of deployment execution.
The plan is stored in a "plan file," usually named sqitch.plan. Sqitch reads the plan file to
determine what changes to execute to change the database from one state to another.
"target"
A named database to which to deploy changes. Always has an associated connection URI, and may also
have an associated command-line client and registry name.
"registry"
The name of the database object where Sqitch's state and history data is stored. Typically a schema
name (as in PostgreSQL and Oracle) or a database name (as in SQLite and MySQL).
"add"
The act of adding a change to the plan. Sqitch will generate scripts for the change, which you then
may modify with the necessary code (typically DDLs) to actually deploy, revert, and verify the
change.
"deploy"
The act of deploying changes to a database. Sqitch reads the plan, checks the current state of the
database, and applies all the changes necessary to either bring the database up-to-date or to a
requested state (a change name or tag).
"revert"
The act of reverting database changes to reach an earlier deployment state. Sqitch reads the list of
deployed changes from the database and reverts them in the reverse of the order in which they were
applied. All changes may be reverted, or changes may be reverted to a requested state (a change name
or tag).
"committer"
User who commits or reverts changes to a database.
"planner"
User who adds a change to the plan.
Options
-C --chdir --cd DIR Change to directory before performing any actions.
--etc-path Print path to etc directory and exit.
--no-pager Do not pipe output into a pager.
--quiet Quiet mode with non-error output suppressed.
-V --verbose Increment verbosity.
--version Print version number and exit.
--help Show a list of commands and exit.
--man Print introductory documentation and exit.
Options Details
"--chdir"
"--cd"
"-C"
sqitch --chdir dbproject
sqitch --cd /usr/local/somedb
sqitch -C dbcheckout
Change to the specified directory before performing any actions. Effectively the same as:
(cd somedir && sqitch ...)
But a bit friendlier when managing multiple projects.
"--etc-path"
sqitch --etc-path
Print out the path to the Sqitch etc directory and exit. This is the directory where the system-wide
configuration file lives, as well as change script templates.
"--no-pager"
sqitch --no-pager
Do not pipe Sqitch output into a pager. Currently limited to the "log" and "plan" commands.
"--quiet"
sqitch --quiet
Suppress normal output messages. Error messages will still be emitted to "STDERR". Overrides any
value specified by "--verbose".
"-V"
"--verbose"
sqitch --verbose
sqitch -VVV
Pass multiple times to specify a value between 0 and 3 to determine how verbose Sqitch should be.
Unless "--quiet" is specified, the default is 1, meaning that Sqitch will output basic status
messages as it does its thing. Values of 2 and 3 each cause greater verbosity. Ignored if "--quiet"
is specified.
"--help"
sqitch --help
Outputs a brief description all known Sqitch commands and exits.
"--man"
sqitch --man
Outputs this documentation and exits.
"--version"
sqitch --version
Outputs the program name and version and exits.
Sqitch Commands
"init"
Create the plan file and directories for deploy, revert, and verify scripts if they do not already
exist. This command is useful for starting a new Sqitch project.
"status"
Output information about the current deployment state of a database, including the name of the last
deployed change, as well as any tags applied to it. If any changes in the plan have not been
deployed, they will be listed separately.
"log"
Search and Output the complete change history of a database. Provides information about when changes
were deployed, reverted, or failed, as well as who planned and committed the changes, and when.
"add"
Add a new change.
"tag"
List tags or tag the latest change.
"rework"
Rework an existing change.
"target"
Manage target databases.
"deploy"
Deploy changes to a database
"revert"
Revert changes from a database.
"verify"
Verify changes deployed to a database.
"config"
Get and set project, user, or system Sqitch options.
"bundle"
Bundle a Sqitch project for distribution. This command copies the Sqitch configuration, plan, and
deploy, revert, and verify scripts to a directory, so that it can be packaged up for distribution,
such as in an RPM or tarball.
"help"
Show help for a specific command or, if no command is specified, show the same documentation as
"--help".
Configuration
Sqitch configuration can be set up on a project, user, or system-wide basis. The format of the
configuration file, named sqitch.conf, is the same as for git.
Here's an example of a configuration file that might be useful checked into a VCS for a project that
deploys to PostgreSQL and stores its deployment scripts with the extension ddl under the "migrations"
directory. It also wants bundle to be created in the _build/sql directory, and to deploy starting with
the "gamma" tag:
[core]
engine = pg
top_dir = migrations
extension = ddl
[engine "pg"]
target = widgetopolis
[revert]
to = gamma
[bundle]
from = gamma
tags_only = yes
dest_dir = _build/sql
[target "widgetopolis"]
uri = db:pg:widgetopolis
And here's an example of useful configuration in ~/.sqitch/sqitch.conf, to point to system-specific
engine information:
[user]
name = Marge N. O’Vera
email = marge@example.com
[engine "pg"]
client = /usr/local/pgsql/bin/psql
[engine "mysql"]
client = /usr/local/mysql/bin/mysql
[engine "oracle"]
client = /usr/local/instantclient_11_2/sqlplus
[engine "sqlite"]
client = /usr/local/bin/sqlite3
Various commands read from the configuration file and adjust their operation accordingly. See sqitch-
config for a list.
See Also
The original design for Sqitch was sketched out in a number of blog posts:
• Simple SQL Change Management <https://justatheory.com/computers/databases/simple-sql-change-
management.html>
• VCS-Enabled SQL Change Management <https://justatheory.com/computers/databases/vcs-sql-change-
management.html>
• SQL Change Management Sans Duplication <https://justatheory.com/computers/databases/sql-change-
management-sans-redundancy.html>
Other tools that do database change management include:
Rails migrations <https://guides.rubyonrails.org/migrations.html>
Numbered migrations for Ruby on Rails <https://rubyonrails.org/>.
Module::Build::DB
Numbered changes in pure SQL, integrated with Perl's Module::Build build system. Does not support
reversion.
DBIx::Migration
Numbered migrations in pure SQL.
Versioning <https://www.depesz.com/2010/08/22/versioning/>
PostgreSQL-specific dependency-tracking solution by depesz <https://www.depesz.com/>.
Author
David E. Wheeler <david@justatheory.com>
License
Copyright (c) 2012-2024 iovation Inc., David E. Wheeler
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial
portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
THE USE OR OTHER DEALINGS IN THE SOFTWARE.
perl v5.38.2 2024-02-08 sqitch(3pm)