Schema Guard
PostgreSQL database schema migration tool that helps manage, control and deploy database schema changes across various environments and development stages.
Automatic SQL generation and plain-SQL approach, flexible options to perform the action at an exact migration stage, build-in ETL.
Declarative
Entire database schema in a single YAML file. Schema Guard makes the SQL for you.
Imperative
Full control on executed SQL. You write the SQL you need.
Zero dependencies
No Java and JDBC, ready to use binary file.
CI/CD Ready
Truly flexible versioning and tagging, including data management by build-in ETL and more.
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.
Declarative
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
Imperative
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
- 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.
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.
Script execution order by types:
- Pre-scripts, run before schema generation
- Schema generation scripts
- Versioned scrips or "post schema scripts"
- Repeatable scripts, handy for stored procedures
(run when changes are detected) - 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.
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?
- Annual price per user. Schema limits apply. Check Flyway/Redgate website for more details.
- Annual price for 10 "Targets" minimum, which is 5K per year. Enterprise is for 10K. Check Liquibase website for more details.
- 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.