What? Supabase?

In my work, I get asked about Supabase regularly. Usually by someone who came across the name in an article or heard it from a developer, and who wants to know whether it's relevant – for their company, their project, their next decision. The honest answer is: it depends. But in many cases, the answer is yes.

This article explains what Supabase is, what it can concretely do, and – this is the part that's missing from most explanations – what each feature means for different types of organisations. Because a tool that cuts a startup's development time in half can send entirely the wrong signal in an enterprise architecture decision. And the reverse is equally true.

Supabase is an open-source backend platform built on PostgreSQL. It provides database access, authentication, real-time functionality, file storage, and serverless functions – all through a unified API and a central dashboard. The goal: developers should be able to set up a complete backend without having to integrate five separate services.

Supabase was founded in 2020, quickly established itself as a serious alternative to Firebase, and is today one of the fastest-growing open-source projects in the backend space. The decisive difference from Firebase: Supabase is built on PostgreSQL rather than a proprietary NoSQL database. That's not a minor detail – it's the decision that makes Supabase interesting for production-critical applications.

Before you can understand Supabase, you need to understand why PostgreSQL is the right foundation.

PostgreSQL is the most advanced open-source relational database in the world. It has existed for over 35 years, is actively maintained, and is used in production systems ranging from small startups to multinational corporations. Building on PostgreSQL means investing in something that won't disappear, won't suddenly change its licensing terms, and for which there is a global market of expertise.

Supabase doesn't reinvent PostgreSQL – it makes it accessible. Every Supabase instance is a fully-featured PostgreSQL database. No proprietary query format, no hidden abstraction. Anyone who knows SQL knows Supabase. And anyone who doesn't will find a visual interface in the dashboard for managing tables, relations, and data.

For a startup, this means building on a technology that scales with you. No migration in three years because the database can no longer meet your requirements. PostgreSQL scales from the first row to billions of records – the same system, the same query model.

For a mid-sized company, it means that internal developers or external service providers who will continue developing the system can work with PostgreSQL. No specialisation in a proprietary system is required. The database layer is documented, standardised, and replaceable.

For an enterprise, it means PostgreSQL is enterprise-grade. Commercial support options exist, the knowledge base is broad, and compatibility with existing database tools, BI systems, and reporting infrastructure is given. The argument that open source isn't suitable for critical systems has not been tenable with PostgreSQL for years.

Authentication is the part of a backend that most developers underestimate – and the one where mistakes are most expensive. Supabase delivers a complete authentication solution out of the box: email and password, magic links, social login via OAuth providers like Google, GitHub, Apple, and others, as well as phone number-based authentication via SMS.

All user management runs through Supabase Auth – registration, login, password reset, session management, token handling. Integration into the frontend is well-documented via SDKs for JavaScript, Flutter, Swift, and other platforms, and is practically manageable.

One important aspect: Supabase Auth is tightly integrated with the database. Row Level Security – more on this shortly – allows access rights at the database level to be directly linked to the authenticated user. This isn't a feature you bolt on afterwards; it's a design principle.

For a startup, this represents a significant time saving. Setting up, securely configuring, and operating your own auth server is demanding – and in an early project phase, it's often not the best use of development time. Supabase Auth can be integrated in hours, not weeks.

For a mid-sized company, the relevant point is integration with existing systems. If an Active Directory, an LDAP server, or an existing single sign-on system is already in place, Supabase Auth reaches its limits. In these cases, I recommend combining Supabase Auth with Keycloak, or using Keycloak as the primary identity provider and connecting Supabase via JWT tokens. This is technically solvable, but it requires configuration effort that needs to be planned for.

For an enterprise, Supabase Auth alone is generally not sufficient. Enterprise authentication requirements – SAML, Active Directory integration, compliance-grade audit logs for access events, differentiated role models across many systems – go beyond what Supabase Auth natively provides. Here, Keycloak is the stronger choice as the primary identity management system, with Supabase as the connected data layer.

Row Level Security – RLS for short – is one of the most powerful features of PostgreSQL, and Supabase makes it accessible. The idea: access rules are not defined in application logic, but directly in the database. A policy specifies which users may read, write, or delete which rows in a table – and this policy is enforced by the database itself, regardless of how the request was made.

This has one decisive advantage: no application-layer bug can accidentally expose another user's data. The access rule sits deeper than the application – it sits in the database.

In practice, it works like this: when a user retrieves their own orders, the database automatically returns only the rows belonging to their account. No WHERE clause that a developer might forget. No middleware that could be bypassed. The restriction is structural.

For a startup, RLS is insurance against a common mistake in early projects: too little time invested in security logic. When RLS is correctly configured from the start, a substantial part of data access security is already handled – even when the team is small and working under time pressure.

For a mid-sized company, RLS is particularly valuable in projects with multiple user groups and differentiated access rights – a customer portal where each customer sees only their own data, or an internal tool where different departments manage different datasets. What previously required multi-layered application logic can be mapped clearly and transparently in the database layer with RLS.

For an enterprise, RLS is a recognised security pattern that can play a role in compliance requirements such as SOC 2 or ISO 27001. Access rules are versionable, auditable, and verifiable independently of application logic. That's a genuine advantage over systems where access logic is distributed across multiple application layers.

Supabase offers real-time subscriptions via WebSockets. This means applications can receive database changes in real time without needing to poll regularly. A dashboard that updates automatically when new data arrives. A chat that displays new messages instantly. A collaborative application where multiple users edit the same record simultaneously and see changes immediately.

Technically, this is based on PostgreSQL's LISTEN/NOTIFY mechanism, which Supabase translates into WebSocket connections via its Realtime infrastructure. It's possible to control precisely which table changes are transmitted – inserts, updates, deletes – and RLS applies to real-time subscriptions as well.

For a startup, this opens up use cases that would otherwise require significant infrastructure effort. A real-time dashboard, a live notification feature, or a collaborative function that would previously have required its own WebSocket server can be integrated with Supabase in an afternoon. That's not an exaggeration – it's the difference between a feature a team builds and one a team leaves out because it seemed too complex.

For a mid-sized company, real-time functionality is often exactly what makes internal tools compelling. A logistics dashboard that displays shipment status in real time. An internal ticketing system that surfaces new entries instantly. A monitoring tool for production data. All of this can be built with Supabase Realtime without any WebSocket infrastructure of your own.

For an enterprise, the questions of scalability and fault tolerance of the real-time infrastructure become critical. Supabase Realtime scales horizontally, but at very high concurrent connections – tens of thousands or more – the architecture needs to be planned carefully, and dedicated real-time solutions like Apache Kafka or custom WebSocket servers may need to be considered. For most internal enterprise applications, Supabase Realtime is sufficient. For publicly accessible services with very high concurrent user load, a more thorough evaluation is warranted.

Supabase Storage is a file storage system integrated directly into the Supabase infrastructure. Images, documents, videos – everything can be uploaded, managed, and served via a simple API. Access rules work analogously to RLS: buckets can be public or private, and for private buckets the same user principles apply as in the database.

Supabase Storage is not a replacement for specialised CDN solutions at very high media volumes. But for most applications – user avatars, uploaded documents, product images in an internal application – it is sufficient and saves the integration of a separate service like AWS S3 or Google Cloud Storage.

For a startup, this means one fewer service. No separate AWS account, no S3 bucket configuration, no separate access management for files. Storage, database, and authentication all run through one platform – with a unified API and unified permissions management.

For a mid-sized company, integration with existing storage solutions needs to be assessed. If an S3-compatible infrastructure or an existing file server system is already in place, you need to weigh whether Supabase Storage replaces or complements these systems. Supabase Storage is S3-compatible and can be configured to point at existing S3 infrastructure – that gives flexibility, but requires technical setup.

For an enterprise, Supabase Storage is generally not the first choice for production-critical media workflows at high volume. For secondary systems, internal tools, or applications with moderate file volumes, it's a pragmatic solution that keeps integration overhead low.

Supabase Edge Functions allow server-side logic to be executed directly within the Supabase infrastructure – without your own server, without a separate deployment pipeline for backend code. Edge Functions are based on Deno, run globally distributed, and are accessible via the Supabase API.

Typical use cases: processing webhooks, handling payments via Stripe, sending emails, calling external APIs, or executing more complex calculations that shouldn't happen in client-side code.

Edge Functions are not a replacement for a full backend framework. But for clearly defined tasks that need to run server-side, they are a lean and well-integrated solution.

For a startup, Edge Functions are the key lever for running without any server infrastructure of your own. Stripe webhook, welcome email after registration, external API integration – all of this can be handled in Edge Functions. The result is an architecture that lives entirely within the Supabase infrastructure and requires no separate backend server.

For a mid-sized company, Edge Functions are interesting for clearly scoped integration tasks – a webhook handler that processes incoming orders from a third-party system, or a function that periodically fetches data from an external source and writes it to the Supabase database. For more complex business logic, I recommend a dedicated backend framework such as NextJS API Routes or a Node.js server, because testing, versioning, and debugging Edge Functions is more involved than with conventional backend code.

For an enterprise, Edge Functions are generally not a primary tool. Enterprise backend requirements – complex business logic, strict testing requirements, differentiated deployment management – fit better into established backend frameworks. Edge Functions can, however, be used sensibly for specific integration tasks that are decoupled from the core logic.

Supabase is open source. This means it can be run on your own infrastructure – completely, without any dependency on Supabase as a vendor. The entire platform is available on GitHub, deployment via Docker Compose is documented, and there is an active community maintaining self-hosted setups.

Supabase Cloud is the hosted version – straightforward onboarding, automatic updates, no operational overhead. The price for that is a dependency on Supabase as a vendor and – depending on the chosen region – limited control over where your data is stored.

This is not a trivial decision. I recommend making it on the basis of three questions: How strict are the data protection requirements? How much internal operational effort can the organisation absorb? And how important is long-term cost control?

For a startup, Supabase Cloud is the right entry point. Onboarding takes minutes, the first projects run immediately, and the cost structure is manageable in early phases. Self-hosting becomes a consideration once the product matures, internal expertise has been built, and cost control or data protection requirements make it necessary.

For a mid-sized company, the question of where data is stored is often the deciding factor. Supabase Cloud offers EU regions, but the company behind Supabase is US-based and subject to the Cloud Act. Anyone who wants to exclude that must resort to self-hosting on European infrastructure – Hetzner being the obvious choice. The operational overhead is manageable with reasonable automation, but it needs to be planned for.

For an enterprise, self-hosting is in most cases the only realistically discussable option. Compliance requirements, internal IT policies, and data sovereignty rule out managed services from US vendors for many data categories. Self-hosting on your own infrastructure or in a certified private cloud is then the right path – and it is technically well-trodden.

This is where it becomes important to be direct.

Supabase is not a finished application. It is an infrastructure platform, not a product you buy and put into production tomorrow. It requires developers who set it up, configure it, and integrate it into an application. That's not a criticism – it's the right expectation to have going in.

Supabase is not a complete identity management solution for complex enterprise scenarios. For single sign-on across many systems, SAML integration, Active Directory connectivity, and differentiated enterprise role models, Keycloak is the stronger choice – as the primary identity provider, to which Supabase is connected via JWT.

Supabase is not a real-time data processing platform for very high data volumes. For event streaming at scale, complex stream processing pipelines, or systems with hundreds of thousands of concurrent connections, dedicated solutions are required.

And Supabase is – still – a young platform. It evolves quickly, which is a good thing. But it also means you need to monitor updates, watch for breaking changes, and occasionally adapt your own implementation. This is true of almost any actively developed platform, but it is more noticeable with Supabase than with a system that has been in enterprise use for a decade.

In my day-to-day work, I regularly see projects investing too much effort in the wrong places. Teams spending weeks building an authentication solution that Supabase delivers in three hours. Architectures fighting against a relational data model because an early decision was made for a NoSQL database that doesn't fit. Backend infrastructure consuming a substantial portion of the development budget before a single line of product logic has been written.

Supabase doesn't solve these problems through magic. It solves them by having carefully chosen which problems to address – and solving those problems well. PostgreSQL as a foundation eliminates the database decision for most projects. Auth out of the box eliminates weeks of development effort. RLS eliminates an entire category of security errors. Real-time without your own WebSocket infrastructure opens up use cases that would otherwise be too demanding to build.

This is not a stack for every use case. But it is a stack that, for the right task, works remarkably well – and does so on a foundation you can commit to for the long term without regret.

If you're facing the question of whether Supabase is the right foundation for your project – I'm happy to work through that concretely with you.