3 ms·

Honestly, I want to like Supabase but a lot of this resonates with me even for a fairly small project. I also ended up with 3 user tables due to RLS limitations

Honestly, I want to like Supabase but a lot of this resonates with me even for a fairly small project. I also ended up with 3 user tables due to RLS limitations: auth users, public user profile info, and private user info (e.g. Stripe customer IDs). PostgREST's limitations also had me going back to an API server architecture because I definitely didn't want to write logic in database functions. The only reason I haven't migrated yet is because I'd have to rewrite the data layer to use Prisma/Drizzle instead of Supabase's PostgREST client, and considering that this is a side project, the problems aren't quite big enough to justify that.

steve-chavez 3y ago
Definitely check out "choose your comfort level"[1]. > PostgREST's limitations also had me going back to an API server architecture because I definitely didn't want to write logic in database functions. Because of PostgREST's philosophy[2], you're expected to write database functions(not necessarily SQL, since PostgreSQL offers many PLs). So if you're not comfortable with that, you can treat PostgreSQL just as a data store and pair it up with your favorite ORM. Supabase doesn't force you to use PostgREST. [1]: https://supabase.com/docs/guides/getting-started/architecture#choose-your-comfort-level https://supabase.com/docs/guides/getting-started/architectur... [2]: https://postgrest.org/en/latest/#database-as-single-source-of-truth https://postgrest.org/en/latest/#database-as-single-source-o...