Show HN: SRTD – Live-reloading SQL templates for Supabase migrations

1 points by t1mmen 14 hours ago

We've been happily building on Supabase for ~two years, two major DX frustrations aside:

1. The iteration cycle for database functions was needlessly complex. Some variation of this workflow was common:

  - Find existing function/view/policy/etc in past migrations
  - Copy to SQL editor
  - Make changes 
  - Test
  - Copy back to migration file
  - Repeat

2. Code reviews were painful since every function modification appeared as a complete rewrite. Adding a single line in a 400-line function results in an entirely new file with +401 lines. No historic context, either. Lots of mental overhead for reviewers.

I have searched for tools/workflows to address this, but have came up short. (https://news.ycombinator.com/item?id=36007640, https://news.ycombinator.com/item?id=37755076)

So, over the holidays I paired with Claude to make SRTD (Supabase Repeatable Template Definitions), addressing these issues with a template-based workflow:

    # Make a template with safely repeatable SQL
    echo "-- some idempotent sql" >> supabase/migrations-templates/my_function.sql
    
    # Edit your SQL templates, changes auto-apply to local DB
    npx @t1mmen/srtd watch
    
    # Generate standard Supabase migrations when ready
    npx @t1mmen/srtd build

Key features:

   * Live-reload for SQL templates (great for functions, policies, views, etc)
   * Single source of truth for database objects, with history/functional git blame.
   * Standard (Supabase) migrations as output
   * Safe iteration with WIP templates that never generate migrations (.wip.sql)

Focus has been on Supabase migrations, but it'll work with any Postgres database using `20250109104647_migration_name.sql` formatted migrations with some configuration adjustments.

Happy to accept PR or issues for other migration file formats (or even DBs).

Project: https://github.com/t1mmen/srtd

Would love to hear your thoughts, feedback, and ideas for improvement!