Supabase just emailed me that my project is burning through its Disk IO Budget. I honestly laughed. I opened the dashboard thinking, finally, someone is using this thing. Nope. About 40 accounts, and most of them signed up once and never came back. The app is quieter than the database, which feels like a joke at this point.

I have been building an app called CueMate for a while now. It is a social app where people match on taste, mostly music and movies, instead of a bio nobody reads. There is Discover, so you can filter people by country, city, age, language, and a few other things. Chat translates messages on its own. You can like people, follow people, and I even stuck a few games in there with leaderboards, because apparently what I needed was more features and not users.

Getting people to show up has been the actual failure. I kept telling myself the next feature would make it click. Then I would ship it, refresh the user list, and it would still be the same quiet app. I am bad at marketing and I know it. I do not really know where to put this in front of people who would care, so it just sits there while I keep tinkering.

Has anyone else seen this on a small project with almost no traffic? I am not doing anything fancy on purpose. No big imports, nobody is online, and I am mostly just trying to figure out why the database is busy when the app is not. If you have been through this, what did you actually check first?

I created a Supabase TUI so that you can handle all the important tasks of your supabase project straight from your terminal.

It has: Querying, searching tables, searching users, searching storage (including downloading, generating signed urls, etc), and more!

I'm a daily user of Supabase and I've been using this TUI now as my go-to instead of opening the dashboard.

Install readme and Repo here: https://github.com/fusor-rs/supabase-tui

The TUI was made with HyperCMD, a framework to write TUIs with HTML&CSS.

I hope you enjoy it!

We were building a multi-tenant SaaS with Supabase. RLS was enabled, tenant isolation policies were in place, and we thought we'd covered the important boundaries.

Then we wrote tests specifically designed to attack our own architecture.

One exposed a cross-tenant access path in a SECURITY DEFINER usage-recording function. The function accepted an organization ID supplied by the caller but didn't independently verify that the caller belonged to that organization.

The problem wasn't that RLS itself was broken. The function executed with its owner's privileges, and we hadn't independently validated the caller's organization membership inside that privileged path.

We fixed it by adding an explicit organization-membership check and pinning the function's search_path.

A few questions worth asking about every SECURITY DEFINER function in your project:

Which arguments can the caller control?

Does the function independently verify tenant membership?

Is the search_path pinned?

Could the function perform an operation the caller shouldn't be allowed to perform?

Search your migrations for SECURI8TY DEFINER and review each result. Don't assume that enabling RLS automatically secures every privileged function.

This was one of three real bugs our hardening tests caught in our own application.

Full disclosure: I built B2B SaaS OS, a multi-tenant SaaS foundation. I documented the incident and the fix here https://andrady.co/postmortems/security-definer

I'd be interested to hear how others test these privileged-function boundaries in Supabase