Why Pulsaride

Most database migrations fail not because the technology is wrong, but because the glue code is impossible to test, impossible to restart cleanly, and impossible to hand off to someone who didn't write it. Pulsaride is a direct answer to that problem.

The glue code problem

When a team migrates a production database, the first thing they write is aBatchConfiguration.java. It starts small: a reader, a writer, a chunk size. Then comes the FK constraint on orders that references customers. Then the partial run that left 3,000 rows in an inconsistent state. Then the filter that worked in staging but silently dropped rows in production.

By the time the migration runs, the Java file is 300 lines long, it has no tests, and the engineer who wrote it has moved on to another project.

That file is glue code. Its entire purpose is to connect a source database to a target database according to a set of rules. None of those rules belong in Java.

You own the structure, we own the consistency

Pulsaride's design principle: the rules that describe what to migrate belong in a format that can be read, reviewed, and version-controlled independently of the application code. YAML is that format.

The rules are not a black box. Every field mapping, every filter, every FK dependency, every expect assertion is explicit in the .yaml files. Pulsaride reads those files and executes them using a proven execution engine — Spring Batch — without requiring you to understand Spring Batch internals.

Why not a black box?

Production migrations require auditability. When a stakeholder asks "why did 47 rows not migrate?", the answer must be findable without reading Java source code. With Pulsaride:

  • The filter that excluded those rows is in migration/orders.yaml
  • The DLQ contains each rejected row with its rejection reason
  • The run history in the dashboard shows exactly what happened and when

No black box. Everything is traceable.

Why not Talend, Informatica, or Airbyte?

Commercial ETL platforms solve a different problem: they connect heterogeneous systems at the data warehouse level, with GUI configuration, scheduling engines, and connector marketplaces. That power comes with significant operational cost — licences, operators, training, and a runtime that runs outside your application boundary.

Pulsaride solves a narrower problem: one-time or continuous migration between two relational databases, in the context of a Java application you already own.It runs inside your Spring Boot process, uses your existing DataSource beans, and adds zero external infrastructure.

The three promises

  1. Declarative — if you can describe the migration in a table, you can run it with Pulsaride.
  2. Restartable — every run is resumable from the last checkpoint. Partial failures are normal; data loss is not.
  3. Auditable — every row, every run, every rejection is logged, queryable, and visible in the dashboard.