An ode to Postgres and Supabase

April 13, 2021
Jonathan Libov

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:

  1. Get the record from DATABASE_VENDOR via API/SQL
  2. Delete the record from your STORAGE_VENDOR via API
  3. Delete the original record from your DATABASE_VENDOR via API/SQL

Doing this in SQL, within Postgres in Supabase, looks like this:

  1. Delete the record from DATABASE_VENDOR

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:

One language to rule them all

They nailed it. Kudos to Supabase.

The second point is captured well in this thread:

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.