ANandrewg·Feb 5, 2026
From the docs: https://github.com/sqldef/sqldef?tab=readme-ov-file#renaming...
You tell it what’s being renamed with a special comment.
In Sqldef: Idempotent schema management tool for MySQL, PostgreSQL, SQLitesqldef
sqldef
Go2019–2026
sqldef / sqldef
sqldef
Idempotent schema management for MySQL, PostgreSQL, SQLite, and SQL Server
5Distinct people
16Mentions
0Explicit recommenders
3.2KGitHub stars
What to know before exploring
What it is
Idempotent schema management for MySQL, PostgreSQL, SQLite, and SQL Server
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- djrobstep/migra · linked in 8 of the same discussions
- skeema/skeema · linked in 4 of the same discussions
- bikeshedder/tusker · linked in 3 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year16 dated mentions
Observed mentions: 2019-01-07 17:36:51 UTC to 2026-02-05 06:19:47 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
16 sourcesThere are a few stand-alone declarative Postgres tools available, including Stripe's pg-schema-diff [1], Tusker [2] which wraps Migra [3], and sqldef [4] which supports multiple DBMS.
For sake of completeness for users of other databases: for SQLite check out stb-tester's migrator [5], and last but not least for MySQL/MariaDB there's my tool Skeema [6].
[1] https://github.com/stripe/pg-schema-diff
[2] https://github.com/bikeshedder/tusker
[3] https://github.com/djrobstep/migra
[4] https://github.com/sqldef/sqldef/
[5] https://david.rothlis.net/declarative-schema-migration-for-s...
[6] https://github.com/skeema/skeema
In Declarative Schemas for simpler database managementThanks! Yeah definitely agree that building out declarative table management for Postgres would be a major effort. A few open source projects I've seen in that area include:
https://github.com/sqldef/sqldef (Go)
https://github.com/bikeshedder/tusker (Python but being ported to Rust)
https://github.com/tyrchen/renovate (Rust)
https://github.com/blainehansen/postgres_migrator (Rust)
Some of these are based on parsing SQL, and others are based on running the CREATEs in a temporary location and introspecting the result.
The schema export side can be especially tricky for Postgres, since it lacks a built-in equivalent to MySQL's SHOW CREATE TABLE. So most of these declarative pg tools shell out to pg_dump, or require the user to do so. But sqldef actually implements CREATE TABLE dumping in pure Golang if I recall correctly, which is pretty coo
Read the rest
l.
There's also the question of implementing the table diff logic from scratch, vs shelling out to another tool or using a library. For the latter path, there's a nice blog post from Supabase about how they evaluated the various options: https://supabase.com/blog/supabase-cli#choosing-the-best-dif...
If you wish to auto-generate migrations, there are declarative schema change tools available for most relational databases. I'm the creator of Skeema [1] which provides them for MySQL, but there are options for other DBs too [2][3][4].
Prisma's migration system actually partially copied Skeema's design, while giving credit in a rather odd fashion which really rubbed me the wrong way. From Prisma Migrate's architecture doc: "The workflow of working with temporary databases and introspecting it to determine differences between schemas seems to be pretty common, this is for example what skeema does." [5]
While I doubt I was the first person to ever use that technique, I absolutely didn't copy it from anywhere, and I'm not aware of any other older schema change systems that work this way. It was certainly never "pretty common" prior to Skeema
Read the rest
or even outside of Skeema. Pretty disappointing when a VC-backed company uses a bootstrapped open source project as free R&D and doesn't even give credit in a respectful manner!
[1] https://github.com/skeema/skeema
[2] https://github.com/djrobstep/migra
[3] https://github.com/k0kubun/sqldef
[4] https://david.rothlis.net/declarative-schema-migration-for-s...
[5] https://github.com/prisma/prisma-engines/blob/6be410e/migrat...
Sqldef: Idempotent Schema Management for MySQL, PostgreSQL, SQLite, SQL Server
1 points · Open discussionSqldef: Idempotent schema management for MySQL, PostgreSQL, SQLite, and more
3 points · Open discussionI work heavily in this space and can add some more details :)
Tusker actually uses Migra to power its functionality: https://github.com/bikeshedder/tusker#how-does-it-work
Tusker's flow is somewhat similar to sqldef https://github.com/k0kubun/sqldef , although the internal mechanics are quite different. Migra/Tusker executes the SQL in a temporary location, introspects it, and diffs the introspected in-memory representation -- in other words, using the database directly as the canonical parser. In contrast, sqldef parses the SQL itself, builds an in-memory representation based on that, and then does the diff that way.
I'm the author of Skeema https://www.skeema.io which provides a similar declarative workflow for MySQL and MariaDB schema changes. Skeema uses an execute-and-introspect approach similar to Migra/Tusker, although each object
Read the rest
is split out into its own .sql file for easier management in version control, with a multi-level directory hierarchy if you have multiple database instances and multiple schemas.
Skeema was conceptually inspired by Facebook's internal database schema change flow, as FB has used declarative schema management submission/review/execution company-wide for over a decade now. Skeema actually predates both Migra and sqldef slightly, although it did not influence them, all were developed separately.
In turn, Prisma Migrate and Vitess/PlanetScale declarative migrations were directly inspired by Skeema's approach, paradigms, and/or even direct use of source code in Vitess's case. (Although they're finally moving to a parser-based approach instead, which I recommended they do over a year ago, as it makes more sense for their use-case -- their whole product inherently requires a thorough SQL parser anyway... and ironically, sqldef is based on the Vitess SQL parser!)
Thanks! I know of a couple Postgres tools that work in a declarative fashion: migra [1] and sqldef [2].
Migra is Postgres-specific. Its model is similar to Skeema's, in that the desired-state CREATEs are run in a temporary location and then introspected, to build an in-memory understanding of the desired state which can be diff'ed against the current actual state. (This approach has also been borrowed by other recent tools, including Prisma Migrate [3]). In this manner, the tool doesn't need a SQL parser, instead relying on the real DBMS to guarantee the CREATE is interpreted correctly with your exact DBMS version/flavor/settings.
In contrast, sqldef supports multiple databases, including Postgres and MySQL (among others). Unlike other tools, it uses a SQL parser-based approach to build its in-memory understanding of the desired state. As
Read the rest
a DB professional, personally this approach scares me a bit, given the amount of nonstandard stuff in each DBMS's SQL dialect. But I'm inherently biased on this topic. And I will note sqldef's author is a core Ruby committer and JIT author, and is extremely skilled at parsers.
[1] https://databaseci.com/docs/migra
[2] https://github.com/k0kubun/sqldef
[3] https://github.com/prisma/prisma-engines/blob/main/migration...
Declarative schema management tools make this much easier. The concept is your schema repo just stores CREATE statements, and the schema management tool knows how to generate DDL to transition between the current state in your DB and the desired state in your repo. Not sure about Google, but Facebook/Meta has used this approach company-wide (via internal / non-open-source systems) for over a decade.
I'm the author of declarative schema management tool skeema (https://www.skeema.io, for MySQL / MariaDB). Some other options in this space are sqldef (https://github.com/k0kubun/sqldef, for MySQL or Postgres) and migra (https://github.com/djrobstep/migra, for Postgres). In MS SQL Server, SSDT DACPACs are also somewhat similar.
In Treating SQL like codeI'm the author of an open-source schema management tool, Skeema [1], which uses a declarative infrastructure-as-code approach: you track your table definitions (and procs, funcs, etc) in a Git repo of *.sql files, typically one CREATE statement per file.
Instead of writing migrations, developers simply add / remove / modify these CREATE statements, going through the same pull request and code review process as for code. The tool knows how to diff the desired state (expressed in the repo) vs the actual state of any database environment (prod / stage / dev, etc) to generate the appropriate DDL.
It's a bit of a paradigm shift relative to traditional mysql and postgres migration tools, but it's an approach that has been used successfully by Facebook internally for nearly a decade. It's also a common approach in the SQL Server world. I've writ
Read the rest
ten a blog post [2] describing some of the advantages of the declarative approach.
Skeema currently only supports MySQL and MariaDB, but some declarative tools for Postgres include sqldef [3] and migra [4].
[1] https://www.skeema.io
[2] https://www.skeema.io/blog/2019/01/18/declarative/
[3] https://github.com/k0kubun/sqldef/
[4] https://github.com/djrobstep/migra
Sqldef: Idempotent MySQL/PostgreSQL Schema Management
2 points · Open discussion> "migration commands based on the git history"... what does that even mean? What does git history has to do with the database?
I'm not sure what git-specific interaction the author is envisioning, but more generally: declarative schema management tools are based on the notion of using a repo to store only CREATE statements. It's an infrastructure-as-code style approach, where to modify an existing table, you just modify the CREATE definition. The tool figures out how to translate this to an ALTER.
I'm the author of an existing tool in this space, Skeema [1], which supports MySQL and MariaDB. Other recent tools in this space include migra [2] and sqldef [3]. From what I understand, in the SQL Server world there are a number of others.
[1] https://www.skeema.io
[2] https://github.com/djrobstep/migra
[3] https://github.com/k0kubun/sqldef/
In ORMs Are BackwardsMy thoughts exactly. But it's a major paradigm shift for those coming from the world of Rails/Django/etc migrations, and that unfamiliarity understandably leads to some initial resistance and skepticism.
fwiw, other declarative tools are starting to pop up -- besides my tool Skeema, some others I've seen recently are Migra [1] and sqldef [2]. And meanwhile a bunch of enterprise tools for MS SQL Server have operated in the declarative fashion for quite a long time, although usually with GUIs instead of being git / pull-request-driven. So I think/hope it's just a matter of time before this concept becomes more widely known.
[1] https://github.com/djrobstep/migra
[2] https://github.com/k0kubun/sqldef/
In Ask HN: How does your development team handle database migrations?Sqldef: Idempotent MySQL/PostgreSQL Schema Management by Sql
4 points · Open discussionAnother option is a schema management tool that doesn't rely on migrations at all. I'm the author of one, Skeema [1], for MySQL/MariaDB. Others include migra [2] for Postgres, and sqldef [3] for MySQL or Postgres.
These all use a declarative approach [4], where the user just specifies the desired new state, by adding or changing the set of CREATE statements. The tool knows how to run the correct DDL to reach that new state.
[1] https://github.com/skeema/skeema
[2] https://github.com/djrobstep/migra
[3] https://github.com/k0kubun/sqldef
[4] https://www.skeema.io/blog/2019/01/18/declarative/
In Why We Chose Rails to Build GitlabShowing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.