DEV Community: Umadhar M

Database Migrations & Seeders: Stop Writing Manual SQL Scripts

Umadhar M — Wed, 29 Apr 2026 18:06:36 +0000

If you've ever said "I forgot to run the ALTER TABLE on production" — this post is for you.

Manual database changes are one of the most common causes of production incidents. A developer adds a column locally, merges the feature, deploys — and the app crashes because nobody ran the SQL on the live server.

Migrations and seeders solve this completely. But the tooling is different for every stack, and most guides only cover one framework. This one covers all of them.

The Core Idea

Instead of running SQL manually, you write versioned migration files as part of your normal code. They get reviewed in pull requests, committed to git, and run automatically during deployment. Nobody forgets a column again.

Two concepts to understand:

Migration — a versioned script for schema changes (CREATE TABLE, ALTER, ADD COLUMN). Applied once, tracked by the framework.
Seeder — scripted insertion of reference or initial data. Always written to be idempotent — meaning it can run multiple times without duplicating data.

Why Not Just Write the SQL Directly?

Many teams start with raw SQL scripts shared over Slack or stored in a scripts/ folder. This breaks down fast:

No guarantee the script ran on every environment
No rollback if something goes wrong
No audit trail of who changed what and when
New developers have no idea what order to run things in

Migration tools solve all of this by tracking every change in a dedicated table in your database. If a migration has already run, it skips it. If it hasn't, it applies it. Simple and reliable.

Quick Example — Python Flask (Alembic + SQLAlchemy)

# Install
pip install alembic sqlalchemy
alembic init migrations

# migrations/versions/xxxx_add_email_to_users.py
def upgrade():
    op.add_column('users',
        sa.Column('email', sa.String(255), nullable=True)
    )

def downgrade():
    op.drop_column('users', 'email')

# Run it
alembic upgrade head

# Check status
alembic current
alembic history

Seeder — always check before inserting to keep it idempotent:

# seed.py
session = Session()
for role_name in ['ADMIN', 'USER']:
    if not session.query(Role).filter_by(name=role_name).first():
        session.add(Role(name=role_name))
session.commit()
print('Seeding complete.')

python seed.py

What About Existing Apps With No Migrations Yet?

This is the most common question. If your app is already running:

Export your current schema as a baseline migration file
Tell the migration tool to mark it as "already applied"
From that point — all future changes go through migration files only
Update your CI/CD pipeline to run migrations on every deploy

For Flask/Alembic specifically, use alembic stamp head to mark the current state as the baseline without running anything. From that point forward, every schema change is a new migration file.

The Full Guide

The complete article covers all 7 frameworks with full code examples:

Spring Boot — Flyway + Hibernate
NodeJS — Sequelize CLI
Python/Django — Built-in migrations
Python/Flask & FastAPI — Alembic + SQLAlchemy
Laravel — Artisan migrations
Core PHP — Phinx
Flutter — sqflite local DB versioning

It also includes:

CI/CD pipeline integration examples
Post-deploy verification scripts for each stack
Idempotency patterns for seeders (MySQL, PostgreSQL, SQLite)
A complete FAQ on common migration mistakes

👉 Read the full guide here: Database Migrations & Seeders Best Practices — The DevTools Online

I also built a free collection of developer utilities at thedevtools.online — tools like SQL Formatter, JSON Formatter, JWT Decoder and 40+ more, all browser-based with no login required.

I Got Tired of Jumping Between 10 Different Sites Just to Format JSON — So I Built My Own

Umadhar M — Thu, 19 Mar 2026 08:45:04 +0000

Every developer knows the drill.

You're deep in a debugging session. You need to quickly decode a Base64 string, or format a minified JSON blob so you can actually read it, or generate a UUID for a test fixture. You open a new tab, search for a tool, land on a site drowning in ads and cookie popups, paste your data in, copy the result, and switch back to your IDE.

Two minutes gone. Flow broken.

I did this dozens of times a day not only for the same but for many others. And one day I just decided — I'll build one place that has all of it.

What I Built

The DevTools Online is a free, browser-based collection of developer utilities. No login. No ads. No data sent to any server.

Some of the tools available:

JSON Formatter & Validator — paste minified JSON, get clean indented output instantly
Base64 Encoder/Decoder — including image to Base64 conversion
UUID Generator & Validator — v4 UUIDs, bulk generation, validation
JWT Decoder — inspect token headers and payloads without any server call
Regex Tester & Generator — test patterns with real-time match highlighting
SQL Formatter — clean up messy query dumps
Code Beautifier — HTML, CSS, and JavaScript formatting
CRON Expression Parser & Creator — finally understand what */5 * * * * means
Password Generator & Strength Checker
Hash Generator (MD5, SHA-1, SHA-256)
DNS Lookup & WHOIS
Timestamp Converter, Age Calculator, Unit Converter
And about 40 more...

The One Thing I Cared Most About: Privacy

A lot of developer tools silently send your input to their servers. That's fine for formatting public JSON, but not when you're pasting JWT tokens, API keys, database connection strings, or proprietary code snippets.

Every single tool on The Dev Tools Online runs entirely in your browser. There's no backend processing your input. Your data never leaves your device.

I made this a non-negotiable from day one. It's why I built it myself instead of just bookmarking someone else's site.

A Few Things I Learned Building This

1. PHP is still great for simple, fast tool sites

I went with a plain PHP + vanilla JS stack. No framework overhead, no build steps, no Node modules folder weighing 300MB. Pages load fast, the codebase is easy to maintain, and deployment is just an GitHub Actions push. Sometimes boring technology is the right choice.

2. .htaccess rewrite rules are both powerful and terrifying

Getting clean URLs (/json_formatter instead of /json_formatter.php) while handling redirects, blocking sensitive directories, and managing cache headers — all in one file — taught me more about Apache than 3 years of casual use did.

3. Browser-based tools are harder to build than they look

When you can't offload anything to a server, you have to handle every edge case in JavaScript. Malformed JSON, circular references, files that are too large, encodings that break on emoji — all of it has to be caught and handled gracefully in the client. It's a fun constraint to work within.

4. Content matters as much as the tools themselves

I initially launched with just the tools and minimal descriptions. Traffic was near zero. I've since added proper documentation to each tool — real examples, use cases, common gotchas. The difference in engagement has been noticeable.

What's Coming Next

I'm actively working on:

A diff checker improvement with side-by-side view
XML to JSON and YAML validator improvements
A curl command builder (something I personally need all the time)
Better mobile experience on tool pages

Try It Out

If you're constantly switching tabs for simple dev tasks, give it a try: thedevtools.online

Everything is free. Nothing requires an account. And if a tool you need is missing, hit the Contact page and let me know — I genuinely read every message.

I'm Umadhar, a software developer from India. Happy to answer any questions in the comments about the build, the stack, or the tools themselves.

Tags: webdev, javascript, php, productivity, opensource