You can either implement the authentication yourself (not recommended) or use an authentication provider. And there are various authentication providers: Auth0 is recognized for its top security (but also top pricing); Firebase Authentication is often treated as the go-to solution when starting a project from scratch (which is the case for us so far). Or there is the Firebase alternative — Supabase.
When evaluating Supabase Authentication compared to Firebase Authentication, one key differentiator is that Supabase uses a PostgreSQL database while Firebase keeps your authentication records hidden from you, accessible only via API or SDK. Supabase Auth stores authentication records in a separate auth schema within PostgreSQL. This gives you full control over your auth records and allows you to use a familiar and powerful relational database for both your API and authentication needs.
In this guide, I’ll explain why Supabase Authentication might be a great choice for you. Especially if you’re building an MVP.
Is Supabase a Safe Choice?
Among the first things that any startup has to resolve when it comes to the selection of technologies is whether the technology is (in no particular order):
- Stable
- Secure
- Well-maintained
- Well-documented
- Ideally widely adopted
- Suitable for the existing tech stack
For these reasons, a relatively new technology like Supabase might be susceptible to doubt when it comes to the above-mentioned concerns. But the stats tell a different story.
Supabase has reached General Availability this year with over 1 million managed databases and over 2,500 new databases launched daily.
If you’re still feeling uncomfortable, 36% of the last Y Combinator batch of companies used Supabase to launch their startup.
According to the official statistics, Supabase is currently in the Top 125 GitHub Ranking repos. Supabase’s rapidly growing open-source community proves an interest from the ranks of developers.
Companies like Udio, Krea, Humata, Chatbase, Pika, Quivr, Mendable, Markprompt and MDN search by Mozilla have all started on Supabase.
That all leads me to the conclusion that with its launch of GA, developers supporting its development and the proven track record of companies that managed to effectively scale using with this technology, Supabase is a valid choice for your startup. In the following text, we’ll focus on Supabase’s core offering — Supabase Authentication.
Authentication Setup
To onboard some users to your app, you first have to let them register. Since your backend likely contains a user domain entity, you may have to create a user record in your database upon registration. Supabase offers multiple ways to achieve this, depending on your setup. Let’s first review the common steps.
The common initial setup steps include:
- Set Up Supabase: Sign up on the Supabase website and create a new project. Access the Supabase dashboard to manage your database and authentication settings. You’re good to go in a couple of minutes.
- Configure Authentication: Supabase supports various authentication methods, including email/password and OAuth providers (like Google and GitHub). Configure these in the Auth section of the Supabase dashboard.
- Create a User Table: In your Supabase database, create a table to store user information. You can reuse fields from the auth schema, such as email and phone. Supabase has its own migration CLI, but you can use any migration tool you like. In Go, we like to use tern.
Now, the way you’d typically work with an external auth provider like Supabase or Firebase is that you’d expect the client (the mobile app or web app) to send an authenticated request containing a JWT token in the Authorization header to the Backend (BE). Your BE then parses and validates the JWT, extracts user-identifiable information from it (such as user ID) and maps it to your database user record. Then, authorization is resolved based on the user’s role or access rights and when successful, the user is allowed to access the requested resource.
Validation of the Supabase-issued JWT token is lightweight compared to Firebase’s ID token validation. With Firebase, you’d want to use a dedicated Firebase library, depending on the programming language of your choice. Some specifics to the ID token validation make it more complicated than just simply checking the JWT signature, which is the case for Supabase. Supabase generates an immutable signature key used to sign issued JWT tokens, which means that your BE can simply use this signature key to validate the incoming JWT tokens. This simplicity has some downsides of course. If you want to change the signature key, you have to obsolete the previous one and reload the new one in your BE. Still, this simplicity also means that our BE is not directly dependent on Supabase (doesn’t need a 3rd party library).
Now that we’ve got the authentication part all set, we need to figure out how to actually create the user record in our database. Depending on your application structure, you have multiple choices. The choices typically depend on which primary database (containing user records) you use for your Backend.
Option 1: Using Supabase as Your Backend Database
Supabase hosts PostgreSQL on AWS, offering a scalable and performant database. Unless you have specific needs, such as advanced time-series calculations and analytics, Supabase is likely a great fit. Moreover, it offers a generous free tier, which is super useful considering how much the database runtime costs on AWS or GCP for example.
Assuming you can use Supabase as your backend database, this setup is straightforward and lightweight. And the best part is that your BE doesn’t even have to know about Supabase. So, how to do that?
You should first create a function that will create a new user record.
CREATE OR REPLACE FUNCTION create_user() RETURNS trigger
LANGUAGE plpgsql AS
$$
BEGIN
INSERT INTO public.users(id,
auth_id,
created_at,
updated_at)
VALUES (gen_random_uuid(),
new.id,
new.created_at,
new.updated_at);
RETURN new;
END;
$$;To execute the trigger every time a new auth record is inserted, you can set up a trigger and execute the above function after each insert to auth.users table.
CREATE OR REPLACE TRIGGER after_user_signup_trigger
AFTER INSERT
ON auth.users
FOR EACH ROW
EXECUTE FUNCTION create_user();The whole flow would look like this:
Option 2: Using a Different Database
If you need a different database — for example, Timescale if you’re processing mostly time-series data or a NoSQL database such as Mongo — your setup will look a bit differently. While here again you have multiple options, starting with using Supabase Edge functions as authentication webhook (which is Supabase’s native functionality), I recommend sticking with the basic client-server communication to avoid various edge cases that occur when not doing so. (By the way, this scenario is also valid for Option No. 1 described above.)
For that, we need to split the sign-in and sign-up (which is effectively the same thing, I’ll explain that in a bit) into 2 steps:
- The registration of the user in Supabase and obtaining a valid signed JWT authentication token.
- The registration of the user on the BE with the authentication token provided by Supabase.
The situation is described in the picture below:
It is often desirable to make the sign-up idempotent*. The client (the mobile device) doesn’t know whether the user is already registered or not, and it’s not possible to separate sign-in and sign-up with SSO authentication providers such as Apple or Google. It is therefore useful for the client to call the sign-up endpoint by default, and if the user already exists, the BE simply skips user creation. Besides the user model, the BE can include a meta field informing the client whether the user entry was created, which can be useful for some follow-up UX logic.
*Idempotent means that calling the endpoint multiple times results in the same response as calling it once.
Phone and Email Verification
Here is a tip that can save you some time and energy. When going with Option 1, you can even further simplify your BE functionality. Phone and email verification is a frequently requested feature, but the implementation is often non-trivial. Supabase by default verifies Phone and Email when you update those user fields through Supabase’s mobile SDK. You only have to prepare a couple of things beforehand.
Phone verification (and the auth itself) requires you to connect to an SMS provider. The supported providers include Twilio and Twilio Verify, Vonage, MessageBird, etc. Once you connect your SMS provider, Supabase will use the provider for both authentication and phone changes (which is neat).
Similarly, you should connect an email SMTP server to send emails from. A popular choice is SendGrid or Resend. SendGrid provides you with more options, advanced analytics, and built-in templates. Resend, on the other hand, is a bit more simplistic and more developer-friendly.
On the BE side, it is then quite useful to reference Supabase’s auth schema directly, rather than duplicating the phone and email fields. That way, you’re sure always to have a verified phone and email on your BE.
Bonus: Authentication Hooks
While still in BETA, Authentication Hooks might be a great addition to your development arsenal. With this feature, you can overcome some of the obstacles you might hit with Firebase Authentication, such as the population of custom claims in the JWT token or dynamic customization of SMS or Email content. I encourage you to take a look at this feature. Oh, and by the way, since Supabase operates mostly on top of Postgres, the hooks can be either SQL hooks or HTTP calls… both of which might come in handy in certain scenarios.
Conclusion
Supabase is a great alternative to Firebase that is in many ways superior. Supabase’s core products – Authentication and Database – are well-established production-grade solutions many companies use. Supabase presents a great solution not only for small businesses who have yet to build their MVPs but also offers scalability and robustness. Supabase's native support for PostgreSQL is especially useful when building minimal products. You can also explore other features that Supabase offers, such as phone and email verification or authentication hooks. These and other features can speed up the development and offload some of the tasks from the engineers.
FAQs
I can’t decide whether to use Firebase or Supabase for Authentication. What do I do?
If you still don’t know, decide based on what you currently have. If you have something from Firebase, use Firebase and don’t worry about it unless you’re feeling experimental. That being said, if you plan on using any of the other Supabase products, I’d encourage you to give it a go.
Can I use Supabase as my backend database without using Supabase Authentication?
Yes. You can still take advantage of Supabase’s generous pricing for the database itself without using Supabase Authentication service.
Can I migrate from Firebase to Supabase? If so, how difficult is it?
Yes, it’s possible. Supabase provides several tools to assist with the migration from Firebase Authentication and from Firebase Firestore. That being said, migrations are always challenging, especially in live environments. Assess the situation carefully in your specific context.
I am already using Firebase Authentication. Should I migrate to Supabase Authentication?
The answer depends on many factors and we would have to assess your specific needs and reasons for migration.
What if I decide to drop Supabase in the future?
Assuming you’re not using Supabase Authentication (meaning you’re not referencing the auth schema described in Option 1), the migration will be possible without any data transformation as long as you migrate to another PostgreSQL database. Since Supabase uses native PostgreSQL, the migration from Supabase will be the same as migrating any PostgreSQL database.
