When we started using Supabase we were looking for some best practices on how to make the most of the toolset. After building a few applications we have compiled a few thoughts that may be helpful to others. 


Our typical stack consists of a frontend (React) that connects to an API (node/express) which then connects to the database (mysql). We are a team of fast prototypers and that is what drew us to Supabase in the first place. After several months of using Supabase, there are things we like, things we are struggling with, and things we do not like.


Supabase offers multiple ways to connect to your data: SDK, database functions, and Deno’s that connect to the db (either through the SDK or to postgres directly).  Each approach has potentially significant ramifications for how my team works and how to scale the development of an application.

1. Using the Javascript SDK to retrieve / write data
This is obviously what is most appealing about Supabase at first - easy access to your database for basic CRUD methods. It makes it super easy to get started. Adding row level security is a game changer and we like how that opens the door for a DBM to own the security layer, leaving the developer free from needing institutional knowledge around data access.
However, in real-world applications we find that we need to compose responses that don't map to database tables. Traditionally, that would be done in the API layer (express) which may retrieve data from multiple tables and transforms records to custom objects. 

Syntax gets complicated on joins and filters when compared to SQL (personal opinion)
Exposing the database topography and linkage between tables is a potential security issue since queries are accessible client side
Chaining database actions (e.g. multiple writes or reads) becomes janky and error prone. For us making successive db calls on the client side is considered bad practice since the frontend is owning too much of the business logic. This creates bloat and introduces complexity that really doesn't belong on on the frontend. 

As a result, we tend to use the SDK for quick prototypes and MVP's or where the data that is needed maps directly to a table schema, such as displaying a user profile. 

2. Using database functions (RPC)
This is somewhat new territory for us coming from a typical API (node/express) setup. In the past we stayed away from stored procedures since they were impractical to deploy and manage. However, we find that with Supabase, they are often the fastest way to read or write data, especially when compared to using a Deno with the SDK which can be 4-10 times slower in our tests.
However, database functions are not ideal:

PSQL is clunky and limited. While there is lots of documentation, it’s poorly presented and depends on the db implementation. We found ourselves doing a lot of trial and error to find out what subset of PSQL was supported by Supabase.
Debugging is a nightmare with cryptic error messages
IDE support in Supabase is very limited. It’s near impossible to effectively edit functions in the IDE. 
The developer workflow is subpar.
We don’t like creating a lot of black boxes in our architecture and that’s what db functions do

We use db functions mostly for aggregates or automations triggered by another database action. For example, increasing counters or creating new rows in a user profile table. Other than that, we think db functions are difficult to scale.

3. Using Deno (invoke)
Using Deno to host backend logic - even an entire API - seems most intuitive to us. We can connect to the db natively or using the SDK (though with a significant penalty of latency) and build a more traditional serverless backend. The integration with the auth layer makes connecting to postgres with RLS seamless. 

We previously used AWS Amplify and found the developer workflow to be so horrific that we stopped. The main issue was around pushing updates which sometimes could take several minutes. Supabase pushes updates to deno instantly with seemingly no delay.

Developer workflow is lacking as each file needs to be pushed separately
Testing of Deno’s locally requires a local setup that mirrors production

As we continue using Supabase, we hope that further improvements to developer workflow will make this the definitive path for us going forward and hope that Supabase will provide more best practices.