Flamingock: Getting Started

This section documents schema/database evolution using version-controlled migration tools — Liquibase (relational/SQL), Mongock (MongoDB, Java-native) and Flamingock (Mongock’s successor, generalized to any external system) — as described by each tool’s own official documentation: liquibase.org and docs.liquibase.com for Liquibase, docs.mongock.io for Mongock, and docs.flamingock.io for Flamingock — which are the references these pages are written and verified against.

This content was generated with the assistance of AI and should be verified against those official docs before being relied on in production.

Mongock is now maintained under the Flamingock GitHub organization (github.com/flamingock/mongock), and Flamingock is positioned as its successor — see Coming from Mongock. Readers starting a new project should default to Flamingock unless they have a specific reason to stay on Mongock.

This section’s bibliography lists the reference material consulted while preparing these pages.

Flamingock is Mongock’s successor: the same code-first idea, generalized so a "change" can target any external system, not only MongoDB. This page covers its guiding philosophy, a first quick-start example, and how to move an existing Mongock project onto it.

Change-as-Code (CaC)

Flamingock’s documentation frames its design around Change-as-Code: every change to any system your application depends on — a database schema, a message queue topology, a third-party API call that must happen exactly once — is committed as versioned, reviewable code, the same as any other application change. Three principles follow from that:

Safety by default — when Flamingock cannot guarantee a safe outcome (a failure partway through, an ambiguous state), it stops and requires manual intervention rather than guessing or silently continuing. This is a stricter default than either Liquibase or Mongock: those tools generally continue past an incomplete run once the failure is addressed, whereas Flamingock is designed to treat "unsure" as a hard stop.
Complete auditability — every change’s execution, across every target system in a pipeline, is recorded in Flamingock’s audit store (Flamingock: Changes & Target Systems), giving one unified history instead of a separate log per target system.
Configurable recovery strategies — how Flamingock responds to a failed change (retry, manual fix required, skip) is configured per change or per stage, rather than being a single fixed behavior for the whole pipeline.

Quick Start

A minimal Flamingock setup targeting MongoDB looks structurally similar to a Mongock @ChangeUnit, but with Flamingock’s own annotations:

@Change(id = "create-person-index", order = "001", author = "alberto", targetSystem = "person-mongo")
public class CreatePersonIndexChange {

    @Apply
    public void apply(MongoDatabase db) {
        db.getCollection("person")
          .createIndex(Indexes.ascending("email"), new IndexOptions().unique(true));
    }

    @Rollback
    public void rollback(MongoDatabase db) {
        db.getCollection("person").dropIndex(Indexes.ascending("email"));
    }
}

targetSystem names which of the application’s configured target systems this Change applies to — here, a single MongoDB target named person-mongo (Flamingock: Changes & Target Systems). Wiring up each target system’s connection details and the audit store happens once, in the application’s Flamingock configuration, not per Change. Flamingock then runs at application startup the same way Mongock and Liquibase’s Spring Boot integrations do (Core Concepts' generic execution flow). See Introduction and Quick start for the full setup steps and dependency coordinates.

Coming From Mongock

Flamingock provides a documented migration path for an existing Mongock codebase, described at Coming from Mongock. At a high level, this means:

Renaming @ChangeUnit → @Change, @Execution → @Apply, and @RollbackExecution → @Rollback (the method bodies themselves are typically unchanged, since both still receive a MongoDatabase or equivalent).
Migrating Mongock’s existing audit history into Flamingock’s audit store, so already-applied change units are not re-run.
Adopting Flamingock’s stage/pipeline grouping (Flamingock: Stages & Pipelines) for changes that were previously just a flat, order-sorted list.

Because Mongock is now maintained under the Flamingock GitHub organization (github.com/flamingock/mongock), this migration is treated by the maintainers as an in-family upgrade rather than a switch to a competing tool — see FAQ for specifics on version compatibility and supported migration scenarios.