Project
Swordfish
A migration assessment harness for getting off legacy databases — see the code, plan it, and do it, without pretending a button can do it for you.
- Open Source
- Python
- postgres
- migration
- ai
- Status
- beta
Swordfish is an assessment and modernization harness for heterogeneous database migrations to PostgreSQL — from Oracle, MySQL, SQL Server, Sybase, and DB2. It reads your codebase and tells you where your database access actually is (including the dynamic, ORM-generated, and wrapped SQL that grep walks right past), what needs to change and how risky it is, and what only a human can decide.
It is a helper, not an autopilot. A four-tier discovery funnel catches the known patterns cheaply and offline, finds the hidden SQL, and uses cross-checked LLMs for the long tail. It recommends a fix for each finding, lets you edit it, and hands a scoped task to whatever copilot you already use — and it never touches your source tree: rewrites land in .new sibling files for you to review. Self-hosted, offline-capable, Apache-2.0.
Every piece of Goldfish content tagged project: swordfish shows up below — the blogs on why migration is a code problem (and the engineering behind multi-model validation and behavioral traps), plus the per-database worked-example tutorials. The tutorials run against the Swordfish Sample Apps.
From this project
Tutorials
-
DB2 → PostgreSQL: A Worked Example
A worked DB2 to PostgreSQL example: FETCH FIRST n ROWS ONLY, SYSIBM.SYSDUMMY1, VALUES quirks, identity columns, and SQL/PL to PL/pgSQL patterns.
-
Moving and assessing Oracle application code to Postgres using Swordfish
Drive the Swordfish web UI through a full Oracle to Postgres assessment of the HR demo: read the grade, find the critical PL/SQL findings, turn 336 findings into a plan.
-
Moving and assessing MySQL application code to Postgres using Swordfish
Drive the Swordfish terminal UI through a full MySQL → Postgres assessment of a real PHP app — find the embedded SQL, read what breaks, export the plan.
-
SQL Server → PostgreSQL: A Worked Example
A worked SQL Server to PostgreSQL example: TOP, IDENTITY, GETDATE/ISNULL/LEN, bracket identifiers, MERGE, and READ UNCOMMITTED habits.
-
MySQL → PostgreSQL: A Worked Example
A worked MySQL to PostgreSQL example: AUTO_INCREMENT, backtick identifiers, ENUM, ON DUPLICATE KEY, GROUP BY ordering, and the dump-to-PG rewrite path.
-
Oracle → PostgreSQL: A Worked Example
A worked Oracle to PostgreSQL example: the constructs Swordfish flags most (CONNECT BY, ROWNUM, NVL, packages), the recommended PG/EPAS change, and the human-review step.
Blogs
-
Why We Run Multiple LLMs (and Make Them Argue)
One model gives you one confident answer. The problem is "confident" and "correct" aren't the same word.
-
Heuristics + AI: Why Deterministic Rules Come First
The cheapest, most accurate part of Swordfish doesn't use AI at all. That's not an accident.
-
The Stuff That Isn't in the Code: Inferred Knowledge and Why Migrations Lose It
Your application knows things it never wrote down. The migration is where it forgets.
-
Swordfish: A Harness for Your Copilot, Not Migration-in-a-Box
We're not trying to replace your LLM. We're trying to make it stop guessing.
-
Why Database Migrations Are a Developer Problem
The schema is the easy part. The code is where migrations go to die.
