Why We Abandoned Firebase For Supabase
Firebase has served us well for many years, however for a lot of our customers we have frequently run into limitations due to the security features of Firestore and Realtime Database.
While we pride ourselves in clean, accessible, responsive web development, we view strong application security as an absolute requirement. This means that we very heavily rely on the security features of the BAAS (backend as a service) provider that we choose.
Before we explain why we are moving away from Firebase, we need to understand what they offer. Firebase has two primary database solutions, first is realtime database. This is a NoSQL database that specializes in realtime updates to your application. If you want a more relational style database, that's where Firestore comes in. While Firestore is still a NoSQL database, it provides api endpoints to emulate a relational database.
Our Main Concerns
Security in large complex applications rapidly approaches unmanageable very quickly. On top of this, you must mimic your security in your front end in order to prevent runtime errors.
Managing permissions in Firebase security rules can become complex. Simple data access is very straight forward, but when you start trying to use other fields in the database to determine a user's access you find a wall of complexity. You must either use lots of security functions to abstract this complexity away, or duplicate data throughout your app in order to have the access data in place when you need it. Both of these methods are very error prone, and we have run into these issues when maintaining applications.
Duplicate Security Code
The Firebase api provides an easy to use client library. This library is great until you request data the user does not have permission to see. By default this will throw a runtime error in the library. You must either handle this error, or not ask for data you cannot see. The end result is every piece of security code must be duplicated and stored in the front end software as well as the database security rules.
Welcome to Supabase
So why supabase?
- SQL (Postgres) database
- Row level security
- Column level encryption
- Client queries return only what permissions allow
Most company data is relational. There is no reason to use NoSQL for the vast majority of the use cases we see. Having Postgres at our disposal makes managing data much easier.
Now the kicker. Supabase allows us to seamlessly utilize row level security within Postgres. This system allows us to request data as a user, and the database will only return the rows that user can see. For Instance, if we say the equivalent of Users.all, the database may return a list of users with only 1 user.
Lastly, being able to specify that a given column should be encrypted at rest provides our clients with a great sense of comfort knowing their data is safe. We do not need to encrypt the whole row, or table, but rather just the data points we care about. Supabase also seamlessly decrypts this data when necessary, allowing our code to access the plain text data when needed.