TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

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

1 pointsby t1mmen4 months ago
We&#x27;ve been happily building on Supabase for ~two years, two major DX frustrations aside:<p>1. The iteration cycle for database functions was needlessly complex. Some variation of this workflow was common:<p><pre><code> - Find existing function&#x2F;view&#x2F;policy&#x2F;etc in past migrations - Copy to SQL editor - Make changes - Test - Copy back to migration file - Repeat </code></pre> 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.<p>I have searched for tools&#x2F;workflows to address this, but have came up short. (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36007640">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36007640</a>, <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37755076">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37755076</a>)<p>So, over the holidays I paired with Claude to make SRTD (Supabase Repeatable Template Definitions), addressing these issues with a template-based workflow:<p><pre><code> # Make a template with safely repeatable SQL echo &quot;-- some idempotent sql&quot; &gt;&gt; supabase&#x2F;migrations-templates&#x2F;my_function.sql # Edit your SQL templates, changes auto-apply to local DB npx @t1mmen&#x2F;srtd watch # Generate standard Supabase migrations when ready npx @t1mmen&#x2F;srtd build </code></pre> Key features:<p><pre><code> * Live-reload for SQL templates (great for functions, policies, views, etc) * Single source of truth for database objects, with history&#x2F;functional git blame. * Standard (Supabase) migrations as output * Safe iteration with WIP templates that never generate migrations (.wip.sql) </code></pre> Focus has been on Supabase migrations, but it&#x27;ll work with any Postgres database using `20250109104647_migration_name.sql` formatted migrations with some configuration adjustments.<p>Happy to accept PR or issues for other migration file formats (or even DBs).<p>Project: <a href="https:&#x2F;&#x2F;github.com&#x2F;t1mmen&#x2F;srtd">https:&#x2F;&#x2F;github.com&#x2F;t1mmen&#x2F;srtd</a><p>Would love to hear your thoughts, feedback, and ideas for improvement!

1 comment

jumski4 months ago
thanks for contributing this! i will definitely check it, was thinking about using <a href="https:&#x2F;&#x2F;atlasgo.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;atlasgo.io&#x2F;</a> for declarative sql code, glad there is another option!
评论 #42672371 未加载