golang-migrate

migrate

Go2018–2025

golang-migrate / migrate

migrate

Database migrations. CLI and Golang library.

Explore on GitHub Read Hacker News discussions

12Distinct people

15Mentions

0Explicit recommenders

19KGitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Database migrations. CLI and Golang library.

GitHub

Where it is used

No documented product use was verified in the last source check.

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: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 year15 dated mentions

Observed mentions: 2018-12-17 18:28:45 UTC to 2025-02-13 18:44:59 UTC.

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.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	2	2
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	2	2
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	2	2
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	4	4
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	2	2
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	2	2
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1

What Hacker News says

15 sources

eberkund·Feb 13, 2025

Is it possible to specify tags to use to install tools specified with the tools directive? I tried the following but it doesn't seem to work (it installs without the tags): go install -tags 'postgres' github.com/golang-migrate/migrate/v4/cmd/migrate@latest

In Go 1.24 Is Released

RadiozRadioz·Nov 16, 2024

Sure, happy to go into it. Firstly we need to distinguish between version control of DQL and DDL. In the context of comparing SQL and Pandas, we're mostly talking about DQL, so version control for this is exactly the same as any other query code. For the DDL side that you're asking about, indeed just version controlling SQL files won't work, you need to use a proper migration tool. There are many available that do pure SQL migrations in the same way Django works (a sequence of up/down operations to perform or revert a migration). Personally I use migrate[1]. So you really can achieve the same thing. Personally I like this approach because it can do anything Django can, but it can also do more complicated migrations that can't be expressed by an ORM's DB-agnostic abstract layer. Pure SQL migrations also decouple your database schema from y

Read the rest

our ORM/framework, which I think is sensible anyway; databases & data tend to be much stickier than apps & frameworks. A downside here is that you need to do some extra work to keep models in sync with the schema. But the point I was making with my original post is that you can totally use ORMs for CRUD and auto-generate away all that boilerplate, _in addition to_ using raw SQL for complicated data analysis. My point is it's not binary, you can mix them, and there's nothing forcing you to generate _all_ your queries if you use an ORM for most of them. Use the ORM to manage schema, then SQL for a one-off query - still works. [1]: https://github.com/golang-migrate/migrate

In Non-elementary group-by aggregations in Polars vs pandas

Sphax·Sep 27, 2024

How do people deploying SQLite server side handle migrations ? I've seen two ways but I'm still not sure which one I prefer: * using an external tool, just like any other RDBMS (I know and use https://github.com/golang-migrate/migrate) * embedding migrations in the app and letting the app manage migrating up.

In Scalable Server SQLite Apps

joaodlf·Aug 14, 2023

First of all, thank you for SQLAlchemy! If I ever had to make a final choice in how I would interact with a database for a very large project that involves a considerable dev team, I would always bet on SQLAlchemy. Not that I would necessarily like all aspects of it, but when it comes to Python and SQL - “Nobody ever got fired for picking SQLAlchemy.”. With that out of the way, despite ORMs doing much more than "just writing SQL", it is exactly on that point that I flinch: Most devs should be exposed to SQL. And if your project allows you to build around simple enough abstractions so that you aren't reinventing the wheel, you should definitely be writing SQL. Especially if you don't know SQL yet - which is the growing case of new devs coming into the job market. You can achieve a lot with SQlAlchemy Core, a tool that I absolutely recommen

Read the rest

d, but my post is just a simple alternative to get developers to think about their approach. If that results in some devs reconsidering using "full fat" SQLAlchemy and to try SQLAlchemy Core, that's a win for me! Your gist tries to highlight the difficulty of doing certain things without an ORM. Migrations (as just 1 example) doesn't need to be hard, simple tools like flyway, or migrate (https://github.com/golang-migrate/migrate) achieve a similar result (while also keeping you on the path of writing SQL!). Deep and complex relationships between objects also don't need to be hard - typically people approach this subject with a requirement to be very flexible in the way they want to build queries and objects, but that to me in a sign that maybe they should reconsider their business logic AND reconsider that, just maybe, their project doesn't require all that flexibility, it is fairly straightforward to extend objects and introduce some more complex representations as and when it is needed - will all of this make me write code faster? Absolutely not. That is why you have spent so much time perfecting SQLAlchemy, but then again, I am not advocating for devs to go and replace their usage of ORMs, just presenting an alternative that may or may not fit their needs for a new project + give devs the chance to learn something that the ORM might have taken away.

In Python: Just Write SQL

joaodlf·Aug 14, 2023

When it comes to migrations, I've been fine with https://github.com/golang-migrate/migrate There are a multitude of extra things to consider, but none of those things are, in my opinion, imperative to having success with SQL in Python. Will it be hard to achieve the same level of convenience that modern ORMs provide? Absolutely. But there is always a cost. I firmly believe that for most projects (especially in the age of "services"), an approach like this is very much good enough. Also, a great way to onboard new developers and present both SQL and simple abstractions that can be applied to many other areas of building software.

In Python: Just Write SQL

xemoka·Dec 14, 2021

If this interest you, both dbmate [https://github.com/amacneil/dbmate] and golang/migrate [https://github.com/golang-migrate/migrate] are in very similar spaces---and can be provided as a single executable.

In Pgmigrate: Write migrations using plain SQL

robmccoll·Oct 25, 2021

I use this https://github.com/golang-migrate/migrate in a deploy step to each environment with the upgrade / downgrade scripts committed to the repo alongside the code. The scripts can do pretty much anything you need to do in PG including defining and executing functions.

In Exploring PL/pgSQL: Strings, arrays, recursion, and parsing JSON

robmccoll·Sep 8, 2021

I've used https://github.com/xo/xo, extended it with some custom functions for templating, extended the templates themselves, and can now generate CRUD for anything in the database, functions for common select queries based on the indices that exist in the database, field filtering and scanning, updates for subsets of fields including some atomic operations, etc. The sky is the limit honestly. It has allowed me to start with something approximating a statically generated ORM and extend it with any features I want as time goes on. I also write .extra.go files along side the generated .xo.go files to extend the structs that are generated with custom logic and methods to convert data into response formats. I like the approach of starting with the database schema and generating code to reflect that. I define my schema in sql files and handle

Read the rest

database migrations using https://github.com/golang-migrate/migrate. If you take this approach, you can mostly avoid exposing details about the SQL driver being used, and since the driver is mostly used by a few templates, swapping drivers doesn't take much effort.

In How We Went All In on sqlc/pgx for Postgres and Go

rkwz·Apr 8, 2021

You can use any normal DB migration tool. For k8s, I put the app's readiness probe to false, run the migrations and then toggle the probe back to true. Here are some migration libraries: Go - https://github.com/golang-migrate/migrate Node - https://github.com/salsita/node-pg-migrate

In The architecture behind a one-person tech startup

domano·Sep 24, 2020

I am convinced that https://github.com/golang-migrate/migrate is enough. We've used it for ~3 years now and if it is enough for a platform with hundreds of scaled containers, including migration from docker swarm to gcp kubernetes and managed sql then it should be enough for all kinds of cases.

In Database Version Control with Liquibase

dgellow·Sep 3, 2020

1. create a "schema_version" table 2. have a unique, incremental migration ID in each migration filename 3. apply them one by one in order depending on the current schema_version from the target environment, and update the schema_version accordingly 4. rollback the transaction in case of error, otherwise commit and enjoy your updated schema I used golang-migrate/migrate in production for the past 3 years to do exactly this but you can easily implement it yourself too. golang-migrate/migrate can be used either as a Go library or as a CLI tool. https://github.com/golang-migrate/migrate Or did I misunderstand the issues you're talking about?

In Show HN: ORM for TypeScript with no query-builder, supporting full SQL queries

stock_toaster·May 10, 2019

We use migrate[1]. [1]: https://github.com/golang-migrate/migrate

In Ask HN: How does your development team handle database migrations?

stock_toaster·Jan 22, 2019

I personally tend to prefer migrate[1] as it doesn't require java. [1]: https://github.com/golang-migrate/migrate

In Why We Chose Rails to Build Gitlab

mythrwy·Dec 17, 2018

Just digging into first Golang application (existing, no structure, everything in one folder except templates and static css etc., no front end JS library). No migrations. Had the exact same question. Was looking at this: https://github.com/golang-migrate/migrate Thinking Vue for front end also. Very timely main post because have been wondering best way to lay structure on the project. Simple is good and sure don't mind getting away from big framework bureaucracy, but 100 files in a folder can't be the way to go.

In Vue.js and Go example project

sambull·Dec 17, 2018

I like go-migrate [0] with postgres and sqlx [1] for just the right amount of orm. [0] https://github.com/golang-migrate/migrate [1] http://jmoiron.github.io/sqlx/

In Vue.js and Go example project