*this post is the 2nd of a 4 part series of posts exploring Supabase, Vercel & Svelte. This post goes deeper into Supabase
Part 1: Intro
Part 2: Supabase
Part 3: Vercel
Part 4: Svelte
In the previous post I outlined why Supabase, Vercel & Svelte make up my current ideal technology stack. This post delves deeper into Supabase and why it has helped me fall in love with full-stack development again.
What is Supabase?
Supabase is a managed service which encompasses (but is not limited to) all of the following: authentication, database, file storage & serverless functions.
Supabase is like other “backend as a service” (BaaS) offerings like Firebase, but with a few notable differences; the project is open-source & is centred around an open-source relational database (Postgres).
What makes it so useful?
As I have lamented in the past, app development is complicated. Anything that reduces stack complexity can help focus developers on the things that really matter.
I tried Supabase for a weekend project for a local charity and achieved so much in a single weekend that I would consider myself an advocate for the product.
Following that experience, I have now used Supabase successfully for two additional production projects and plan to use it in the future for similar scenarios (small team startups).
Creating a relatively simple app over a weekend is not a huge accomplishment. There are other services and no-code platforms that can do something similar in the same timescales.
However, experience has taught me to get into the weeds with a product and then extrapolate into the future to gauge the real value of a tech stack. Low code and no-code tools are great, but at some point, in a growing project, you will hit a wall.
What makes Supabase stand out is that coupled with other developer tools like Svelte, it can be at least as productive as no-code tools without the drawbacks e.g. vendor lock-in, limited customization, up-front costs and scalability.
Embracing Open-Source and Community
My gravitation towards Supabase is also influenced by its open-source ethos which promotes transparency, collaboration, and community-driven innovation.
Being open to open source is more than just being idealistic, it’s also pragmatic.
The Supabase project is open source e.g. the code that runs its managed service can be downloaded and used on a server of your choosing.
If Supabase decides to increase the managed service cost to a level where it no longer makes sense to use it, you can manage the services yourself elsewhere.
Supabase has been completely transparent about its open-core business model from the start, hopefully, this model continues to work for them.
However, relying on open-source projects is not without potential pitfalls, especially when open-source companies’ heads get turned by greedy VCs and start over profiteering.
At one time, Elastic was my tool of choice for multi-faceted search, but the change in licence by the company has left a bad taste.
However, even though open-source licences can change, it is still better than the closed-source alternative where you are completely at the vendor’s whims from day one.
Simplifying the Complex
Creating apps is a complicated process even without having to worry about managing servers.
Delegating responsibility for managing auth, database, and storage to a managed service allows small teams to concentrate on more impactful concerns.
Not only does Supabase take these concerns away from you but it does it all in an easy-to-use dashboard.
The developer experience in general has been, dare I say it, enjoyable.
Using the Supabase tools and libraries has successfully reduced the complexity and lines of code in my apps.
The Security Model: Easy to Understand
The simplicity of the row-level security model in PostgreSQL is easy to configure and understand.
It presents a straightforward yet robust framework that drastically reduces the risk of misconfiguration—making security accessible to all of the team, even for newcomers, from day one.
However, it’s not perfect.
I have had experience in the past with different approaches to securing data. My least favourite way in the past was to implement the security rules totally in code i.e. lots of if/then statements hidden away in code that only the core developing team could understand or change.
In contrast, in my opinion, the “best” way I have experienced is to use declarative authorization rules, defined in the data schema e.g. Amplify authorization rules.
In the example below, any user can read from the “Todo” table/graphql type, but only the person who created the row can update or delete their own data.
## Configure schema and auth rules
## in one place
type Todo
@model
@auth(rules: [{ allow: public, operations: [read] }, { allow: owner }])
{
content: String
}## Implementing something similar
## using Postgres/supabase
create policy "Allow select, update and delete for users based on id" on "public"."Todo" as permissive for all to public using ((auth.uid() = id));
create policy "Read for all users" on "public"."Todo" as permissive for select to public using (true);It would be great if Supabase could cater for the type of declarative security as above, if anyone knows if it can, please reach out.
Scalability and Performance: Meeting Tomorrow’s Needs Today
In the past, I have spent countless hours trying to eek out marginal gains in performance in case my app goes viral. Spoiler alert… it didn’t… and I’ll never get those hours back.
Let someone else (with probably more expertise) obsess about performance and scalability.
Supabase’s seamless scalability ensures that as you grow, your backend does too—smoothly and reliably. This peace of mind allows you to focus your energies on innovation and enhancing user experience, secure in the knowledge that your technological foundation is a given.
The Cost-Effectiveness of Dreaming Big
In the world of startups, where every resource counts, Supabase’s pricing model is perfect.
The free tier is generous enough to battle-test your idea. The follow-on tiers are predictable and fair.
It’s not just about infrastructure costs where Supabase shines. The comprehensive savings in developer hours it enables through its exceptional developer experience is significant.
Again, this efficiency allows you to channel resources into areas that directly amplify user value and platform growth.
A Comparison with the Giants
In my career, I have used other back-end-as-a-service offerings and Supabase compares favourably for the projects I’ve been doing lately i.e. small team startup.
I have used all of the following comparable technologies in production environments: Firebase, Retool, AWS Amplify, Budibase.
I have tried, but not implemented the following tools: Planetscale
I have not tried, but want to look at, the following: Parse, NHost, Backendless, AppWrite
My advice, if any is needed, is to look at your particular situation and try out any or all of the tools above on a pet project.
The “try out” part is key, all these sites have wonderful marketing websites which promise the earth. It’s not until you get down into the weeds on developer experience and pricing that the suitability becomes clearer.
*this post is the 2nd of a 4 part series of posts exploring Supabase, Vercel & Svelte. This post goes deeper into Supabase
