Hi! Very excited to share my project spawn, a db migration/build system. For now, it supports PostgreSQL via psql to create and apply migrations, as well as write golden file tests. It has some innovations that I think make it very useful relative to other options I've tried.

GitHub: https://github.com/saward/spawn

Docs: https://docs.spawn.dev/

Shout out to minijinja (https://docs.rs/minijinja/latest/minijinja/) which has made a lot of the awesomeness possible!

Some features (PostgreSQL via psql only for now):

- Store functions/views/data in separate files

- Git diff shows exactly what changed in a function in new migrations

- Easy writing of tests for functions/views/triggers

- Env specific variables, so migrations apply test data to dev/local db targets only

- Generate data from JSON files

- Macros for easily generating repeatable SQL, and other cool tricks (e.g., view tear-down and re-create)

I started this project around two years ago. Finally have been able to get it to an MVP state I am happy with. I love using PostgreSQL and all its features, but current available tooling makes utilising some of those features more challenging

I created spawn to solve my own personal pain points. The main one was, how to manage updates for things like views and functions? There's a few challenges (and spawn doesn't solve all), but the main one was creating and reviewing the migration. The typical (without spawn) approach is one of:

1. Copy function into new migration and edit. This makes PR reviews hard because all you see is a big blob of new changes.

2. Repeatable migrations. This breaks old migrations when building from scratch, if those migrations depend on DDL or DML from repeatable migrations.

3. Sqitch rework. Works, but is a bit cumbersome overall with the DAG, and I hit limitations with sqitch's variables support (and Perl) for other things I wanted to do.

Spawn is my attempt to solve this, along with an easy (single binary) way to write and run tests. You:

- Store view or function in its own separate file.

- Include it in your migration with a template (e.g., {% include "functions/hello.sql" %})

- Build migration to see the final SQL, or apply to database.

- Pin migration to forever lock it to the component as it is now. This is very similar to 'git commit', allowing the old migration to run the same as when it was first created, even if you later change functions/hello.sql.

- Update the function later by editing functions/hello.sql in place and importing it into your new migration. Git diff shows exactly what changed in hello.sql.

Please check it out, let me know what you think, and hopefully it's as useful for you as it has been for me. Thanks!

(AI disclosure: around 90% of non-test code by me, AI was used more once the core architecture was in place, and for assisting in generating docs)