An ode to Postgres and Supabase
We’re building our product in Supabase. A few weeks into building, Supabase introduced storage, which shipped with you one of the most pleasant surprises of my product-manager-who-shouldn’t -be-coding-career career. I’ve been waiting 10 years for this:
What’s happening here is that when the record for an image is deleted, Postgres is removing the corresponding image object from storage. The code lives in Postgres; in virtually all other apps, the code for doing this lives in the app and looks something like this:
Doing this in SQL, within Postgres in Supabase, looks like this:
The fact that the former procedure is easily achievable by a student in their, I don’t know, 17th day of Lambda School, misses the point. Well, it misses two points. The first is that seemingly small choices like this can generate outsized outcomes when you’re recruiting a next-decade cohort of customers. Being able to
LEFT JOIN storage to records is
AWESOME. This, from Supabase’s introductory blog post for storage, conveys it well:
They nailed it. Kudos to Supabase.
The second point is captured well in this thread:
justin's rule: all no-code eventually converges to yes-code over time— justin (@itunpredictable) May 28, 2020
basically, at some point the UI becomes so unwieldy and hard to use that SQL is a superior UX https://t.co/VfUNeqRPKy
What SQL has over everything else is that it’s close-to-the-metal and easy for any product-person-who-shouldn’t-really-be-coding to understand. It takes a couple days to learn, sure, but that’s good friction. Teaching other people in my org SQL has been the most consistently rewarding (for me and the org) things I’ve done in my career, as you get to watch people cross the chasm from afraid-of-monospace-fonts to team-member-whose-curiosity-is-limited-only-by-their-own-ambition.
For similar reasons, Supabase has been one of the consistently delightful platforms I’ve used in some time, and a long time coming.