CLI to Manage Your SQL Database Schemas and Migrations

Posted2 months agoActive2 months ago

PonyM

36 points

19 comments

github.comTechstory

supportivepositive

Debate

20/100

Database ManagementSQLCLI Tools

Key topics

Database Management

SQL

CLI Tools

The HN community shares and discusses 'shed', a CLI tool for managing SQL database schemas and migrations, with users appreciating its simplicity and functionality.

Snapshot generated from the HN discussion

Discussion Activity

Moderate engagement

First comment

31m

Peak period

0-2h

Avg / period

2.4

Comment distribution19 data points

Loading chart...

Based on 19 loaded comments

Key moments

01Story posted
Nov 2, 2025 at 1:23 AM EST
2 months ago
Step 01
02First comment
Nov 2, 2025 at 1:54 AM EST
31m after posting
Step 02
03Peak activity
6 comments in 0-2h
Hottest window of the conversation
Step 03
04Latest activity
Nov 3, 2025 at 11:18 AM EST
2 months ago
Step 04

Generating AI Summary...

Analyzing up to 500 comments to identify key contributors and discussion patterns

Discussion (19 comments)

Showing 19 comments

Shorel

2 months ago

2 replies

Good may be an alternative to Alembic, so we can get rid of the Python requirement =)

(Checks it out...)

Ahh, this is also Alembic.

Hasnep

2 months ago

1 reply

I've been looking at Atlas as an alternative to Alembic recently, it seems nice, but I'm wary of the non open source features.

https://github.com/ariga/atlas

rubenvanwyk

2 months ago

Also weary of the non open source features.

leosanchez

2 months ago

1 reply

I use goose[1] for db migrations.

[1]: https://github.com/pressly/goose

ghthor

2 months ago

Goose is great, been using it for many years and is my goto db schema manager.

Love how you can write you migrations in go using goose and mix in raw sql migrations as well. Allows for great flexibility when doing complicated migrations and enables writing unit tests for migrations with regular go test

juangacovas

2 months ago

1 reply

I like when projects like this mention other projects. "Phinx" (PHP) has been a breeze to work with for database migrations for years now, and handles more than my team needs. Meanwhile, some time ago a colleague in other job was raging they didn't have migrations but a chaos of DBs in their environments.

hdjrudni

2 months ago

This one company I worked for created like 5 databases for every client they had.

So we had hundreds of databases. And no migrations or way to keep them in sync.

One day I got fed up and ran some statistical analysis on all the databases to find inconsistencies and figure out what the most popular schemas were, because sometimes even when they had the same table and column names, the types were slightly different.

I don't recall if I managed to get them all in sync before I quit.

whilenot-dev

2 months ago

1 reply

> This will create a config file for local and prod databases using sqlite for local and postgres for prod.

Hold on, people actually do that? I thought it's trivial to run your database in a container locally.

dewey

2 months ago

1 reply

Especially if you use any of the features that make Postgres nice to work with (For example good jsonb handling) these are immediately different than on sqlite and then won't work for development. Don't think there's a good reason for not running the same DB in both environments.

aforwardslash

2 months ago

1 reply

You dont even need to look into advanced features; sqlite does not support ILIKE.

evanelias

2 months ago

To be fair, most databases don't, since ILIKE is not in the SQL standard.

bytefish

2 months ago

1 reply

If you are using SQL Server, then SQL Server Database Projects are an amazing tool to work with. I found them to generate high-quality migration scripts and it makes it easy to diff against an existing database.

ORMs are good up until the point you need to include SQL Views, Stored Procedures, Functions, User-defined Types… which is usually the point the ORM abstractions begin to crack (and every SQL Server database I use include them).

For PostgreSQL I usually hand-write the scripts, because it is easier, than fighting against an ORM.

I heard the Redgate tooling is also great to work with, but I’ve never used it personally.

a8m

2 months ago

Good point regarding ORMs - that was one of the main problems I wanted to tackle when we built Atlas (https://atlasgo.io). We added support for reading ORM definitions directly, then let you extend the "base schema" defined in them. For example, you can define your models in SQLAlchemy, EF Core, Ent, or others as a partial schema, and then extend it with functions, views, and additional objects.

From there, Atlas handles diffing, planning, and execution. This is similar to importing modules in TF, but for database schemas in Atlas. See this example: https://atlasgo.io/guides/orms/sqlalchemy

Disclaimer: I'm involved with Atlas.

_def

2 months ago

1 reply

Tangential, but anyone can suggest their favorite SQL client? Many years ago on Windows I enjoyed HeidiSQL, and while you can kind of use it with wine, it doesn't make a stable impression to me.

Recently I found mycli[1], which seems slightly better than the official mariadb cli client, but still a bit cumbersome.

[1] https://github.com/dbcli/mycli

hu3

2 months ago

Same boat.

https://github.com/HeidiSQL/HeidiSQL is very fast but crashes sometimes.

https://github.com/dbeaver/dbeaver is stable but slow/heavy.

8cvor6j844qw_d6

2 months ago

I mostly used ORM to manage db changes.

bob1029

2 months ago

If you happen to be using MSSQL or Postgres, the Redgate tools are a game changer for schema management. I was a big fan of using things like EF and custom code to handle schema migrations until I tried SQL Compare. These tools make normalizing a large number of instances significantly easier. If you've got a multi tenant setup where everything should have the same schema, you could fix the whole fleet in an afternoon.

For SQLite, I still vastly prefer using custom code to run migrations. Something about the ownership model makes manual external tooling feel inappropriate.

notorandit

2 months ago

If it's a declarative tool, then "yes, thanks".

But if it's not, then "no thanks", I already have my native CLI tools bundled with my RDBMS.

sdssddxxffds

2 months ago

Yhhjkj

View full discussion on Hacker News

ID: 45788202Type: storyLast synced: 11/20/2025, 12:47:39 PM

Want the full context?