Rumba RDBM

Rumba is a database schema migration tool for PostgreSQL that helps manage, control and deploy database schema changes across various environments and development stages.

It employs the automatic SQL generation and plain-SQL approach in one software. Scripts can be assigned with a version and a certain migration phase, which brings developers true flexibility to perform the action at an exact migration stage.

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 Rumba 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

Rumba 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.

  • 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.

  • 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 Rumba RDBM
  • 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.

Rumba 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 Rumba 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, Rumba 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, Rumba 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, Rumba 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

Rumba 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. Rumba 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, Rumba 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 Rumba identify the owner app.

Review and sign-off with multiple delivery strategy

Rumba 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.