Plain-SQL and Automatic SQL Generation

We kept in mind different approaches used in the real-world database-driven applications development and maintenance. That's why Schema Guard supports both: declarative and imperative database schema definition.

One tool for both rapid development and full lifecycle tracking of executed SQL. You can start with declarative schema definition and continue with full-featured strict DBA approval procedure.


Schema Guard gives you an essential boost when your project is at startup phase. You can define and migrate an entire database schema with a single file in YAML format. There you declare your tables.

  • Single schema file that is easy to manipulate with diff and merge
  • Easy to propagate updated schema into all environments
  • No changeset, as a predefined linked list required
  • No unique version or order required on schema files
  • Schema might include data in CSV format


Full control on executed SQL as well as script execution tracking when your projects is at production or maintenance phase. There you restrict to exact SQL to be execute.

  • Set of script types to satisfy DevOps and Dev/DBA needs
  • Special scripts to run after history log commit
  • In-script defined transaction configuration
  • Seamless mixed of SQL statements and YAML/CSV definitions
  • Full-featured PostgreSQL support
Key features
Schematic illustration of database migration process with Schema Guard
  • Can create the new databases
  • Supports encrypted connections with certificate files
  • Full declarative schema definition in YAML format
  • Script execution tracking
  • Build-in ETL to include data into schema migration
  • Schema dump into YAML with data to CSV for review, compare and edit
  • Support separate database connection for history table
  • Native PostgreSQL script support, runs psql for script execution
  • Does not require JVM or Python to run
  • Transactions with rollbacks or configurable non-transactional mode per script
  • Dry run with SQL statement revie

Rapid Development

When working on their project part, developers can make database schema changes locally, then commit them to the version control system. All the parts can be merged into a single schema file. This approach can significantly boost the development.

Schema Guard supports versioning with schema definition in readable YAML format. So it is possible to define a set of changes as a separate versioned schema files and aggregate all content into a single one.

Developers commit changes to Git then the master schema file used for scheduled database migration
Why Schema Guard facilitates Continuous Development
  • Developers make database changes in their branches according to the assigned ticket.
  • Apply schema changes on-premises, perform development and testing.
  • Commit and download changes to Git.
  • Create Pull Request to the master branch, and merge the changes. The database schema is presented as a simple text file, and is easy to merge.
  • Other developers can download changes, merge the schema file, and apply it to their local database.

Besides versioning, Schema Guard provides developers with typing. The schema files or scripts can be assigned to a certain stage of the database migration process. It allows to split the migration into: pre-schema generation phase, schema generation, post-schema phase where versioning is most useful and after-migration scripts.

Scripts assigned to particular database migration stage
Script execution order by types:
  1. Pre-scripts, run before schema generation
  2. Schema generation scripts
  3. Versioned scrips or "post schema scripts"
  4. Repeatable scripts, handy for stored procedures (run when changes are detected)
  5. After migration scripts, run at the end of all database migrations

All steps are optional, scripts run with respect to version number.

How schema scripts work:
  • Upon starting the application, Schema Guard recursively scans the source directory for SQL and other supported file types.
  • Found files are checked for the required version to apply.
  • The target database is checked for already applied versions, Schema Guard computes necessary changes to create or alter the tables.
  • Any incoming changes will be applied in version order and then by file type.
  • The history is updated to prevent future execution of versioned scripts, except the after-migration ones.
Reverse Engineering

Schema Guard brings developers the ability to make database schema snapshots in a YAML format, then feed them to other tools for further analysis. Reverse Engineering is a common and regular part of the development process.

Comparing schemas between environments is possible with some limitations, not all features can be loaded from PostgreSQL System Catalogs.

CI/CD for New Features, Patches, and Bug Fixes

Building an application in CI/CD way may require a previously prepared database to run it. Schema Guard supports this scenario and allows versioning, tagging, and labeling to define changes required for a particular application build.

Specific features or bug fixes may have different sets of changes and deployment schedules. Changes might be bundled and deployed once every few months, unlike bug fixes that usually need to be deployed asap. By tracking the executed scripts and calculating the scripts for each environment and target app, Schema Guard makes this possible.

Several microservices use a singled migration history database
Microservice capable

You can have a single migration history database for all of your microservice applications. Just tag and label your scripts to help Schema Guard identify the owner app.

Review and sign-off with multiple delivery strategy

Schema Guard is a tool to audit all changes shortly after a development cycle is completed. It supports an automatic SQL generation from declarative schema file and versioning of immutable hand-written SQL scripts. Both methods will be available during a dry run. It is up to an organization and its development team to use either or combine both.

Why Us?

Schema Guard
SQL execution tracking
Yes. Versioned, Immutable and Repeatable scripts
Can create SQL for you
For a single migration
For entire DB from a single mutable file
Full control on SQL
Full psql support
Build-in ETL
Can create target DB
Including logging DB, if used
Schema comparison
Through a change set required to make identical DB instances
By comparing any schema dumps in the YAML-format
Copy history journal for monitoring
JVM or other heavy dependencies
JVM required
JVM required
Ready to run binary, only psql required
Open source
Only community edition
Only community edition
No, source code available for audit purposes
Full-featured Free Version
Yes, for personal use
Pro version starts from
$504/year schema/user limited1
$500/year target (min 10)2
  1. Annual price per user. Schema limits apply. Check Flyway/Redgate website for more details.
  2. Annual price for 10 "Targets" minimum, which is 5K per year. Enterprise is for 10K. Check Liquibase website for more details.
  3. Minimum transaction is $1,000, this is equal to 5 names to a particular host or database for one year. Wildcard-connections like "Any host" OR "Any Database"sold for $4,500 per year (semi Enterprise). You can have an "Unlimited" aka Enterprise license for $9,000 per year.

all prices as of stated at owners website without guaranties neither includes fees and taxes.