StackRender V1.1.0 is out: Generate Database Migrations from ER Diagram Changes

#database #schema #webdev

Hey engineers

Schema evolution is still one of the most painful parts of backend/database development.

I tried multiple tools and workflows (ORM auto-migrations, schema diff tools, etc.), but most of them either add complexity, or hit limitations where you eventually end up writing migrations manually anyway , especially when you care about safe production changes.

So I started building a tool around a simple idea:

Design your database as an ER diagram, track diagram changes over time, and automatically generate production-ready migrations from the diff.

I like to call this approach visual-first database migrations.

1 . How it works

You start with an empty diagram (or import an existing database).
StackRender generates the base migration for you, deploy it and you're done.
Later, whenever you want to update your database, you go back to the diagram and edit it (add tables, edit columns, rename fields, add FK constraints, etc).
StackRender automatically generates a new migration containing only the schema changes you made. Deploy it and keep moving.

2 . Migrations include UP + DOWN scripts

Each generated migration contains two scripts:

UP → applies the changes and moves your database forward
DOWN → rolls back your database to the previous version

Migration up script :

Migration rollback script :

3 . Visual-first vs Code-first database migrations

Most code-first migration tools (like Node.js ORMs such as Prisma, Sequelize, Drizzle, etc.) infer schema changes from code.

That approach works well up to a point, but it can struggle with more complex schema changes. For example:

❌ Some tools may not reliably detect column renames (often turning them into drop + recreate)
❌ Some struggle with Postgres-specific operations like ENUM modifications, etc.

StackRender’s visual-first approach uses a state-diff engine to detect schema changes accurately at the moment you make them in the diagram, and generates the correct migration steps.

4 . What can it handle?

✅ Table changes

Create / drop
Rename (proper rename not drop + recreate)

✅ Column changes

Create / drop
Data type changes
Alter: nullability, uniqueness, PK constraints, length, scale, precision, charset, collation, etc.
Rename (proper rename not drop + recreate)

✅ Relationship changes