Versioning Spring Boot Databases with Flyway
Use Flyway's Spring Boot starter to apply versioned SQL migrations on startup and keep schema in sync across environments.
Loading…
ReadMeFeed / Community knowledge
#flyway
Real questions. Useful conversations. Find the people who know your stack.
Managing Versioned SQL Migrations with DataGrip's Attach Directory
Stop guessing if your SQL migrations will fail. Learn how to use DataGrip's Attach Directory feature to get dialect-aware validation and ordered execution for Flyway and Liquibase scripts.
datagripDBeaver ER Diagrams: Live and Offline Schema Visualization That Actually Helps Onboarding
DBeaver's ER Diagram works live and offline from migration scripts, with force-directed and hierarchical layouts, filtering, and PlantUML/Mermaid exports for version-controlled docs. Includes a Flyway-to-Markdown pipeline and real-world limits on layout persistence, large schemas, and implicit FKs.
dbeaverFlyway versioned undo scripts vs. repeatable migrations for zero-downtime rollback
Rollback strategy for zero-downtime deployments Our team uses Flyway 10.x with PostgreSQL 15 in a blue-green deployment pipeline. We need to guarantee that a failed schema change can be rolled back within 30 seconds without data loss or manual intervention. The current baseline uses versioned migrations (V1__..., V2__...) with manually written undo scripts (
npssKtor + Exposed: Coordinating Schema Migrations Across Stateless Instances
Context Ktor handles HTTP routing and coroutine-based concurrency while Exposed provides the SQL DSL and DAO layer for persistence. Schema evolution in Exposed relies on SchemaUtils.createMissingTablesAndColumns , which performs additive DDL only and lacks a built-in version history or rollback mechanism. Problem When multiple stateless Ktor instances start
ktorUsing Postgres 16 with Spring Boot 3.3.0
I just upgraded from spring-boot 3.2.3 -> 3.3.0. After the upgrade flyway refuses to connect to postgres: Caused by: org.flywaydb.core.api.FlywayException: Unsupported Database: PostgreSQL 16.2 at org.flywaydb.core.internal.database.DatabaseTypeRegister.getDatabaseTypeForConnection(DatabaseTypeRegister.java:105) at org.flywaydb.core.internal.jdbc.JdbcConn
Transactional Migration Rollback Boundaries with ManagedDataSource
Goal Define a reliable rollback strategy for Flyway migrations executed within a Dropwizard application using ManagedDataSource so that a failed schema change leaves no partial database state. Constraints and Uncertainty Dropwizard 2.x configures the data source with setAutoCommit(false) for explicit transaction control, yet DDL statements issued by Flyway o
dropwizardDoes Flyway's undo command reliably reverse schema changes without data loss?
Problem Statement Flyway's undo command is designed to reverse applied migrations, but its reliability when handling complex schema changes remains unclear. The feature requires developers to manually write undo scripts, which introduces human error risk and lacks automated detection of data-destructive operations. Constraints and Uncertainty The core challe
railway