What are we doing

The aim of this work is to allow Flyway to more easily use non-JDBC database connectivity. Flyway was originally built around JDBC so the structure of the API heavily influences Flyway's architecture and capabilities.

JDBC requires each request to be a separate statement. In some cases this is trivial but some databases require a complex parser with Flyway to break down a migration into it's component statements. This doesn't particularly add value, it's just a requirement of the JDBC API and so using a native driver, like mongosh, simplifies Flyway by leveraging existing capabilities of 3rd party tools.

In the case of MongoDB, the existing JDBC support is provided by a JDBC wrapper around mongosh but we're not totally happy with the library (it's slow and large in Flyway). By moving onto the new implementation you gain greater performance as Flyway can directly call mongosh as well as allowing use of the JSON migration type that was previously not possible.

Availability

We're releasing this initially in the open source version of Flyway (v11.1.0) - getting MongoDB to work up till now required some effort of manually adding libraries to the released version and so we wanted to prioritize simplifying this.

The new functionality is present in the Redgate edition but we've turned it off by default as the release already has a functioning MongoDB driver. We've also temporarily disabled the Flyway Desktop integration whilst we make sure everything is working correctly. 

How to use the new connector

We've tried to make it a straightforward transition and you can find out more at:

• Tutorial - Using Native Connectors to connect to MongoDB
• MongoDB database driver

The environment variable: "FLYWAY_NATIVE_CONNECTORS=true" will set Flyway to use the new driver .

Work in progress

There are some limitations on the new driver as we wanted to get something into people's hands sooner. 

Mixed JSON/Javascript migrations with MongoDB

JSON migrations are executed using the MongoDB API and Javascript migrations use Mongosh and we can't currently support a mixture of types within one Flyway project.

Please let us know if this a significant constraint for you

Transactions

Transactions are only supported with JSON migrations, Javascript migrations are deployed using Mongosh and will not execute in transactions - this affects the default behavior as well as any explicit parameters that influence this (group, mixed, executeInTransaction).

It is the same behavior as the legacy driver but please let us know if this a significant constraint for you

Callbacks

We have implemented the most commonly used callbacks in Flyway 11.3.0 (2025-01-30)

• afterMigrate
• beforeMigrate
• beforeValidate
• beforeEachMigrate
• afterClean
• beforeClean

This covers the vast majority of callback usage but Please let us know if you have a use case that needs others 

Script Migrations

These are used to invoke a script rather than directly deploy changes to the database

Please let us know if this a significant constraint for you

Locking the Schema History Table

This is required if you have multiple Flyway instances attempting to change your database simultaneously. This is typically an issue when using the Flyway  API in a java application.

Locking the schema history table is not currently supported 

Previous limitations

• Placeholders - Implemented in Flyway 11.2.0 (2025-01-16)
• Validating migration naming - Implemented in Flyway 11.1.1 (2025-01-07)