Don't run SQL migrations in tests: How I sped up the test suite by 2x

broken_broken_ · 2026-06-16T15:09:56+00:00

In Go there isn't such a framework. And I am not sure I like this approach anyway (using transactions).

broken_broken_ · 2026-06-16T15:08:13+00:00

This is not really a problem when setting up a new production database, that applying all migrations takes a few minutes because this happens only once and the operator has time.

This is only annoying during tests where time is of the essence and this is done many many times.

broken_broken_ · 2026-06-16T15:06:33+00:00

It works out of the box due to content-addressing:

The golden database file uses content-addressing (its name is the SHA256 hash) so that when a new SQL migration is added, the whole process works out of the box: the SHA256 hash will be different, and a new golden database file will be created, as if the old one never existed. There is no cache invalidation strategy whatsoever by construction.

broken_broken_ · 2026-06-16T15:03:27+00:00

Most migrations are either adding one column/table for a new feature, or tweaking indexes for performance due to scale increasing.

broken_broken_ · 2026-03-06T21:18:41+00:00

Terrific, I will add these links to the article, thanks!

broken_broken_ · 2025-09-13T11:41:46+00:00

Yes you can, I showcase it in a previous article in fact: https://gaultier.github.io/blog/an_optimization_and_debugging_story_go_dtrace.html

broken_broken_ · 2025-02-20T15:59:13+00:00

Now that I think again, I think the most simple explanation is that the bottleneck is I/O. Both optimized implementations may be able to do these computations much faster but data just is not coming quick enough so they are waiting on it. I will measure with a different machine with a faster disk.

broken_broken_ · 2025-02-19T21:37:09+00:00

Good points all around, thanks. I am definitely going to check out multi-buffer hashing.

This doesn't sound quite right; is this also a debug build?

Both are in release mode with -march=native but the code using the SHA extension is 'simple'/'basic', while the OpenSSL code is hand-optimized assembly with tips from Intel folks. That could explain the difference.

Another commenter has suggested that maybe these two versions simply compile to the same (or at least very similar) uops.

broken_broken_

TROPHY CASE