HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
peterldowns
pgmigrate
Go2023–2025
peterldowns / pgmigrate

pgmigrate

a modern Postgres migrations CLI and library

2Distinct people
9Mentions
0Explicit recommenders
106GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

a modern Postgres migrations CLI and library

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

No other repository is repeatedly linked in the same discussions.

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:03:16 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 month9 dated mentions

Observed mentions: 2023-07-11 14:33:30 UTC to 2025-12-23 15:26:27 UTC.

0122023-07-01 00:00:00 UTC to 2023-08-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 commentsJul 20232023-08-01 00:00:00 UTC to 2023-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-09-01 00:00:00 UTC to 2023-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-10-01 00:00:00 UTC to 2023-11-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-11-01 00:00:00 UTC to 2023-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-12-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2024-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-02-01 00:00:00 UTC to 2024-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-03-01 00:00:00 UTC to 2024-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-04-01 00:00:00 UTC to 2024-05-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-05-01 00:00:00 UTC to 2024-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-06-01 00:00:00 UTC to 2024-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-07-01 00:00:00 UTC to 2024-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-08-01 00:00:00 UTC to 2024-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-09-01 00:00:00 UTC to 2024-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsSep 20242024-10-01 00:00:00 UTC to 2024-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-11-01 00:00:00 UTC to 2024-12-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2024-12-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-01-01 00:00:00 UTC to 2025-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-02-01 00:00:00 UTC to 2025-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-03-01 00:00:00 UTC to 2025-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-04-01 00:00:00 UTC to 2025-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-05-01 00:00:00 UTC to 2025-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-06-01 00:00:00 UTC to 2025-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-07-01 00:00:00 UTC to 2025-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-08-01 00:00:00 UTC to 2025-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-09-01 00:00:00 UTC to 2025-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-10-01 00:00:00 UTC to 2025-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-11-01 00:00:00 UTC to 2025-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2025-12-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsDec 2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Jul 20232023-07-01 00:00:00 UTC2023-08-01 00:00:00 UTC211
Aug 20232023-08-01 00:00:00 UTC2023-09-01 00:00:00 UTC000
Sep 20232023-09-01 00:00:00 UTC2023-10-01 00:00:00 UTC000
Oct 20232023-10-01 00:00:00 UTC2023-11-01 00:00:00 UTC101
Nov 20232023-11-01 00:00:00 UTC2023-12-01 00:00:00 UTC000
Dec 20232023-12-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
Jan 20242024-01-01 00:00:00 UTC2024-02-01 00:00:00 UTC000
Feb 20242024-02-01 00:00:00 UTC2024-03-01 00:00:00 UTC000
Mar 20242024-03-01 00:00:00 UTC2024-04-01 00:00:00 UTC000
Apr 20242024-04-01 00:00:00 UTC2024-05-01 00:00:00 UTC101
May 20242024-05-01 00:00:00 UTC2024-06-01 00:00:00 UTC000
Jun 20242024-06-01 00:00:00 UTC2024-07-01 00:00:00 UTC000
Jul 20242024-07-01 00:00:00 UTC2024-08-01 00:00:00 UTC000
Aug 20242024-08-01 00:00:00 UTC2024-09-01 00:00:00 UTC000
Sep 20242024-09-01 00:00:00 UTC2024-10-01 00:00:00 UTC101
Oct 20242024-10-01 00:00:00 UTC2024-11-01 00:00:00 UTC000
Nov 20242024-11-01 00:00:00 UTC2024-12-01 00:00:00 UTC202
Dec 20242024-12-01 00:00:00 UTC2025-01-01 00:00:00 UTC000
Jan 20252025-01-01 00:00:00 UTC2025-02-01 00:00:00 UTC000
Feb 20252025-02-01 00:00:00 UTC2025-03-01 00:00:00 UTC000
Mar 20252025-03-01 00:00:00 UTC2025-04-01 00:00:00 UTC000
Apr 20252025-04-01 00:00:00 UTC2025-05-01 00:00:00 UTC000
May 20252025-05-01 00:00:00 UTC2025-06-01 00:00:00 UTC000
Jun 20252025-06-01 00:00:00 UTC2025-07-01 00:00:00 UTC000
Jul 20252025-07-01 00:00:00 UTC2025-08-01 00:00:00 UTC000
Aug 20252025-08-01 00:00:00 UTC2025-09-01 00:00:00 UTC000
Sep 20252025-09-01 00:00:00 UTC2025-10-01 00:00:00 UTC101
Oct 20252025-10-01 00:00:00 UTC2025-11-01 00:00:00 UTC000
Nov 20252025-11-01 00:00:00 UTC2025-12-01 00:00:00 UTC000
Dec 20252025-12-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

9 sources
pg_dump has a few annoyances when it comes to doing stuff like this — tricky to select exactly the data/columns you want, and also the dumped format is not always stable. My migration tool pgmigrate has an experimental `pgmigrate dump` subcommand for doing things like this, might be useful to you or OP maybe even just as a reference. The docs are incomplete since this feature is still experimental, file an issue if you have any questions or trouble https://github.com/peterldowns/pgmigrate
In Instant database clones with PostgreSQL 18
That's close, but not what I meant — that's specific to this package, and is the interface for processing log records produced by a slog.Logger. What I mean is that there should be a single interface for Logging that is implemented by slog.Logger, uber/zap.Logger, etc. that library authors can use without needing to reinvent the wheel every time. For an example from one of my own libraries, see https://github.com/peterldowns/pgmigrate/blob/d3ecf8e4e8af87...
In Logging in Go with Slog: A Practitioner's Guide
Overall I agree with this. For dumping just the schema definitions, I'm not that happy with it. My primary use-case for a schema dump is to run it after applying migrations in dev/ci, so that if two engineers each open their own branch with incompatible schema migrations, someone gets a git conflict. In this situation, pg_dump is really annoying because it will give you a schema-only dump, but that dump is not "stable". In the sense that - dump the schema - create a new database from the schema - dump the schema again often gives you two different files in the two different schema dumps, due to minor re-ordering of tables/statements. The other use case I rely on is just having a single place where the schema is defined is actually super helpful for debugging, and can be an entrypoint for other tools. Sometimes it's nicer to b
Read the rest
e able to open that up in your editor rather than have to explore through `psql` or read through many smaller migration files. Because pg_dump does not generate a stable dump (same schema == same file contents), you're constantly getting noise or irrelevant changes to the file, which makes it essentially unusable or at least very annoying if you keep that file committed. > Now, I expect that somebody is going to point out that pg_dump does not solve the dependency problem 100% reliably in all cases. And that's correct. However, I think that complaint just shows how spoiled PostgreSQL users are. Recreating a complex database schema without a dependency-aware tool like pg_dump is an absolute nightmare. If you're interested in a tool that is dependency-aware, AND allows you to explicitly specify dependencies for the cases that pg_dump doesn't handle (primarily between functions and other objects, iirc), check out my cli tool pgmigrate [0]. You don't need to use it to manage your migrations, you can just use the `dump` subcommand. It's a little under-documented, and it's missing some obvious improvements (can't handle multiple postgres schemas (namespaces) right now, only lets you dump one at a time), but I've been relying on it and using it with pleasure. [0]: https://github.com/peterldowns/pgmigrate
In Why Pg_dump Is Amazing
I've been writing Golang for years now, and I heavily endorse everything written here. Only exception is you should use my migration library [0] instead of tern — you don't need down migrations, and you can stop worrying about migration number conflicts. One other suggestion I'll make is you probably at some point should write a translation layer between your API endpoints and the http.Handler interface, so that your endpoints return `(result *T, error)` and your tests can avoid worrying about serde/typeasserting the results. [0] https://github.com/peterldowns/pgmigrate
In Some Go web dev notes
Selfishly, I'd love a documentation review if you (or anyone else) has the time to take a try out some golang projects I've been working on. The code is frankly not very polished and not worth reviewing, but I'm curious to hear feedback on the documentation / README and whether or not you clearly understand what these libraries are for and how to use them. * https://github.com/peterldowns/pgtestdb * https://github.com/peterldowns/testy * https://github.com/peterldowns/pgmigrate
In Show HN: Goralim - a rate limiting pkg for Go to handle distributed workloads
Flyway is generally the most popular. Django/alembic in the python world. I think most migration tools are missing a lot of features that would make them safer and easier to use. Modern teams merge a lot and deploy frequently, but most migration tools are built for a db admin manually running commands. I wrote a migration cli tool (and golang library) that I think is more suited to modern workflows, if you check it out I’d appreciate any feedback! https://github.com/peterldowns/pgmigrate
In Pgroll: zero-downtime, reversible schema migrations for Postgres
Pretty good overview from Baldur — I don't always agree with everything he writes but this seems relatively correct. One question I'd ask him (and anyone else reading) is: what are some other options for monetization? Over the last few weeks I had three different VCs reach out to me about some of the open source projects I've been releasing, and ask me if I'd thought about making a business out of them. I told them that no, based on the problem the software was solving, I didn't see how I could adopt open-core or companion-saas business models, and I wasn't sure how else it could be done while keeping the code open source. Can anyone suggest a viable business model that would allow: * Code remains at least source available, ideally open source for non-commercial use. * I can charge for commercial use. * Actually doing the licensing is rea
Read the rest
sonable, ie no spyware or phoning home from the tool. Wouldn't need to be perfect, I understand that if the code is open source a company could easily fork and use it without paying me. The idea would be to make it zero-headache to pay me for a license if the code is being used by a funded team. The projects: * https://github.com/peterldowns/localias * https://github.com/peterldowns/pgmigrate
In Free and open source software projects are in transition

Show HN: Pgmigrate, modern Postgres migrations CLI

Hi HN, pgmigrate is a postgres schema migrations tool that is designed for modern deployment and operations. You can use the CLI or Docker container to manage migrations for projects in any language but if you use Golang it's also available as a library. The github readme has the full explanation, but basically pgmigrate is "migrations done correctly" or "migrations without all the pain in the ass bullshit": * pgmigrate uses postgres advisory locks to make it parallelizable * It doesn't make you think about down migrations — they're not useful and unnecessary and a waste of time * It runs out-of-order migrations * It doesn't error if you and a coworker both commit migrations with the same sequence number * It has ops commands for the rare occasions you need to manually mess with the migrations table state * And it lets you turn schema con
Read the rest
flicts into git conflicts by making it easy to dump your schema in a consistent format * Oh, and you can squash migrations, too I'd love to know what you think, and I hope that I can convince you to try it out. The plan is to charge businesses money for it while keeping it free for personal and open source use, sort of like Orb stack, but keeping the source open. Are there any features you'd like to see added? The main one I've heard people ask for is automatic migration generation via diffing, like migra or skeema, but I'm not convinced it's useful enough to be worth the implementation hassle.
2 points · Open discussion

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.