Philosophy
You own the structure.
We own the consistency.
Pulsaride is a Java library for data migrations. This is what we believe about the problem — and what we refuse to do because of it.
Migrations are a configuration problem dressed as an engineering problem
Most migration bugs are not logic bugs. They're configuration bugs: a wrong column mapping, a missing null handler, a silent type coercion that rounds a decimal. The underlying transform is almost never the hard part. The hard part is making the configuration explicit, validated, and auditable.
Every team that writes a custom BatchConfiguration.java ends up re-solving the same four problems: DQ assertions, a dead-letter queue, FK ordering, and restart safety. Pulsaride solves them once, declaratively, in YAML.
Silent failure is the worst failure mode
A migration that completes but silently corrupts 3% of rows is worse than one that fails at row 50,000. At least a failure is visible. Silent corruption only surfaces in production, months later, in an incident.
This is why every field in Pulsaride can carry an expect: assertion. A row that violates expect: "> 0" does not silently write a zero to the target — it lands in the DLQ with a structured record: primary key, field name, actual value, rule violated. The job continues. Your audit trail is complete.
Your data never leaves your infrastructure
Pulsaride is a Java library. It runs inside your Spring Boot application, on your infrastructure, with your credentials. There is no cloud control plane, no SaaS dashboard that touches your data, no agent to deploy, no license server to authenticate against.
The monitoring dashboard at /pulsaride runs in the same JVM as your migration. Your run logs are files on your disk. Your DLQ is a table in your database. Everything is yours.
Why not just use Spring Batch directly?
Spring Batch is a general-purpose batch framework. It does not know what a migration is. Every team using it for migrations writes the same boilerplate: an ItemReader per source, an ItemProcessor for transforms, an ItemWriter per target, then invents their own DQ layer, their own DLQ, their own FK ordering, their own restart logic.
Pulsaride is what that boilerplate should have been. It uses Spring Batch internally where it makes sense — but you never configure a Job, a Step, or a Tasklet. You write YAML. The engine handles the rest.
What Pulsaride is not
Not an ETL platform.
Pulsaride does not replace Flink, Spark, or Kafka Streams. It is designed for one-time or periodic database migrations, not continuous stream processing at petabyte scale.
Not a schema migration tool.
Pulsaride does not manage DDL. It does not create tables, add columns, or run Flyway scripts. It moves and transforms data between tables that already exist.
Not an ORM.
Pulsaride does not model your domain. It does not replace Hibernate. It is a JDBC-level engine that reads rows, applies YAML-declared transforms, and writes rows.
Not a SaaS product.
There is no hosted version, no per-row pricing, no vendor lock-in. It is an Apache 2.0 Java library.
If this resonates, the quickstart takes under five minutes.