Software · Architecture · Supabase

Why Supabase became part of our stack.

At some point the front end stops being the hard part. You need identity, permissions, data, APIs, files and backend processes that all have to work together.

That is where Supabase became useful to the way we build at Eden Software.

We do not use it because it removes the need to understand backend architecture. We use it because it gives us a strong backend foundation without forcing us to rebuild the same infrastructure every time we start a product.

At its core, Supabase gives us a PostgreSQL database surrounded by services for authentication, storage, APIs, realtime functionality and Edge Functions. That combination lets us spend more time on the business rules and workflows that make each product different.

Infrastructure should make the product possible. It should not become the product.

Authentication is only the front door

Signing somebody in is one problem. Deciding what they are allowed to see and do is another.

Supabase Auth gives applications a practical identity layer, but the important part for us is how that identity can connect to permissions in the database. A staff member, administrator, organisation and customer can all be authenticated successfully while requiring very different access to the same system.

That distinction between authentication and authorisation matters as soon as software contains real operational data.

The database can enforce the rules

One of the most useful parts of the stack is PostgreSQL Row Level Security.

RLS lets access rules operate at database level. Instead of relying entirely on the interface to hide information somebody should not see, policies can determine which records they are actually authorised to retrieve or change.

That is a much stronger security boundary.

Hiding an admin button is not security. Preventing the underlying request from accessing the record is.

Supabase recommends enabling RLS on exposed tables and provides the tooling to combine those policies with authenticated user identity. Their RLS documentation explains the model in detail ↗

We use Supabase as infrastructure, not as the product

Our applications are not “Supabase apps.” Supabase is one component of the architecture.

The workflows still belong to us. The business logic still belongs to us. The user experience, integrations, controls and product decisions still have to be designed around the actual problem.

That matters because it keeps the architecture from becoming platform-led. We choose the technology because it supports the system, not the other way around.

Edge Functions are where it gets more interesting

Not every operation should happen in the browser.

Applications often need to call another service, process a webhook, protect a secret, send a notification or perform trusted backend logic. Supabase Edge Functions give us a server-side TypeScript environment for those jobs.

Across our product environments we use backend functions for areas including identity, authentication, APIs, administrative processes, notifications and system health.

That is a very different role from simply storing records in a hosted database. Supabase becomes part of the operational layer underneath the software.

Supabase Edge Functions documentation ↗

It changes how you see the architecture

Once these pieces are connected, an application becomes easier to think about as a controlled flow:

User → Authentication → Permission → API → Database → Backend process → Response

That is more useful than thinking about software as a collection of screens.

It forces better questions earlier: Who owns this record? What role created it? Who can approve it? Should the client be allowed to perform this operation directly? Does it belong server-side? What gets logged? What happens when an external provider is unavailable?

Those are architecture questions, not interface questions.

Managed infrastructure still requires discipline

Supabase does not magically make an application secure.

You can still configure authentication badly. You can still write the wrong RLS policy. You can still expose a secret, grant a role too much authority or design a poor database.

A managed platform provides controls. Engineering determines whether those controls are used properly.

That is why we treat Supabase as a useful part of the stack rather than a substitute for architecture, governance or security review.

Why we keep using it

For us, the advantage is speed without having to surrender architectural control.

We can establish a PostgreSQL-backed environment, connect identity, define access policies, expose controlled APIs and add server-side functionality without assembling the same backend foundation from scratch every time.

That leaves more engineering time for the things that actually make the product valuable: the workflow, the rules, the users, the integrations, the controls and the problem the software exists to solve.

That is what good infrastructure should do.

Quietly make it possible to build the product properly.