Technologies / Supabase
Supabase app development on a real Postgres database
Supabase app development gives a mobile team managed sign-in, file storage, realtime updates and server functions, all built on a full Postgres database rather than a proprietary data store. You get much of the speed of a backend-as-a-service with the reporting power and portability of SQL. This page is for founders and CTOs checking whether Supabase fits, and what it takes to run it safely.
Supabase is one of the backends in our mobile app backend development service and our mobile app development technologies overview.
- RLS on every exposed table
- Schema changes as versioned migrations
- Self-hosting path documented
- Project in your own account
The Supabase building blocks we use
According to the Supabase documentation, every project gets “a full Postgres database, not a Postgres abstraction”, and the other services are built on it.
Postgres database
Tables, foreign keys, joins, views, indexes and SQL functions. Relational data such as orders, line items, vendors and payouts fits naturally, and reporting is a query, not an export job.
Auth
Managed sign-in whose user IDs Postgres policies can read directly, so access rules live next to the data. Apple’s login rules for iOS apps that offer third-party sign-in are part of our authentication and SSO work.
Realtime
Live updates so a booking status, a chat message or a delivery update appears without a refresh. We scope realtime to the screens that need it rather than subscribing to whole tables.
Edge Functions and Storage
Server-side functions for logic that must not run on the phone, such as payment webhooks, price checks and calls to third-party APIs with secret keys. Storage holds images and documents, with access rules tied to the same users.
Row Level Security: the part that decides whether your data is safe
With Supabase, the mobile app talks to the database through an API using a public key that ships inside the app. Anyone can extract that key. What stops one user reading another user’s orders is Row Level Security (RLS), which Supabase describes as “a Postgres primitive”: rules on each table that decide which rows a request may see or change.
Supabase’s RLS guide says to “Enable RLS on every table in an exposed schema”. RLS is not switched on automatically for every new table, so a table added in a hurry can be readable by anyone with the app. This is the most serious Supabase mistake we see in code we take over.
How we handle RLS
- RLS enabled on every table in the exposed schema, checked by a CI script that fails the build if one is missing
- Policies written per action (select, insert, update, delete) using auth.uid(), which returns the requesting user’s ID
- Sensitive columns such as roles, prices and balances changed only by server-side functions, never directly by the client
- Policy tests that sign in as different test users and confirm what each can and cannot read
- Admin tools use a separate server-side key that never ships in the mobile app
When Supabase app development is the right call
Supabase fits apps whose data is relational from day one: marketplaces with buyers, sellers and orders; booking apps with staff, slots and payments; B2B tools with companies, users and permissions. Postgres handles those relationships and the reporting on them without the workarounds a document database needs.
It also suits teams worried about lock-in. Supabase is open source under the Apache-2.0 licence and can be self-hosted, with Docker as the recommended route. Your data is standard Postgres, so leaving means moving a database, not rewriting a data model.
It is a weaker fit for apps where offline use is central, because Firebase’s offline cache is more mature. For a side-by-side view, read our Firebase vs Supabase comparison, or see Firebase app development for the other option.
Supabase fits when
- Your data has clear relationships and needs reporting
- You want SQL skills, not a proprietary query model
- Lock-in or data residency is a concern
- A self-hosting option matters to your buyers
- Realtime is needed on some screens, not everywhere
Choosing between Supabase and a custom backend?
Send us your feature list. Within one business day you get our recommendation, the RLS model we would use and the point where a custom API would start to make sense.
What we build with Supabase
Most of our Supabase projects are MVP builds and early-stage products that expect to grow without changing database. Typical examples are booking and scheduling apps, marketplaces with an admin panel and dashboard on the same database, internal field tools with photo uploads, and B2B apps where each customer company sees only its own data through RLS.
As products grow, we often add a small API beside Supabase for complex payment flows, heavy integrations or long-running jobs, while keeping Auth, Storage and the database. Because everything is Postgres, a Node.js or Python service can read the same tables with no sync layer.
Supabase compared with other backends
How Supabase app development compares with the alternatives we build.
| Supabase | Firebase | Custom API (Node.js, Laravel, Django) | |
|---|---|---|---|
| Data model | Postgres (relational, SQL) | NoSQL documents | Your choice, usually Postgres |
| Access control | Row Level Security in the database | Security rules | Code in the API |
| Offline support | Built per app | Strong, built into SDKs | Built per app |
| Lock-in | Low; open source and self-hostable | Higher | Lowest |
| Time to MVP | Fast | Fastest | Slower; more to build |
| Best for | Relational data, reporting, portability | Realtime, offline-first, document data | Complex logic and heavy integrations |
How Supabase fits your stack, team and running costs
Supabase works with the mobile stacks we build in, whether Flutter, React Native or native. On the app side, we put all Supabase calls behind a repository layer so screens never query tables directly. That keeps RLS assumptions in one place and makes a later move to a custom API a single-layer change.
On the team side, the skill that matters is Postgres, not Supabase. Developers who understand schemas, indexes, migrations and policies will be productive quickly. When you hire backend developers for a Supabase project, test SQL and security thinking first.
We do not quote Supabase prices here because plans change. Costs follow plan level, database size, compute and bandwidth, so the levers are familiar ones: index the queries the app runs most, paginate lists, resize images before upload and archive old data.
Code-quality practices on our Supabase projects
What you can check in your project and repository.
- Schema, policies and functions stored as versioned SQL migrations in the repository
- CI check that fails if any table in an exposed schema has RLS disabled
- Policy tests run as several test users before every release
- Separate development, staging and production projects
- Server-side key used only in Edge Functions and admin tools, never in the app
- Indexes for every query used by a main app screen
- Scheduled database backups with a tested restore procedure
Supabase app development: frequently asked questions
Is Supabase good for production mobile apps?
Yes, for the right app. Every Supabase project is a full Postgres database, with Auth, Storage, Realtime and Edge Functions built on it, so it handles relational data and reporting well. The main condition is security: Row Level Security must be enabled and tested on every exposed table. Apps that depend heavily on offline use may be better served by Firebase.
What is Row Level Security and why does it matter?
Row Level Security is a Postgres feature that decides, per table, which rows a request may read or change. In Supabase the app uses a public key that anyone can extract, so RLS is what keeps each user’s data private. RLS is not on automatically for every new table, so we enable it on each one and test it in CI.
Can we self-host Supabase?
Yes. Supabase is open source under the Apache-2.0 licence, and its documentation recommends Docker as the fastest way to self-host. Most clients start on the hosted service and keep self-hosting as an exit option or for data-residency needs. Self-hosting means you run upgrades, backups and monitoring yourself, so budget for that operational work.
Should we choose Supabase or Firebase?
Choose Supabase if your data is relational, you need SQL reporting or you want low lock-in. Choose Firebase if realtime sync and strong offline support matter most and your data is document-shaped. Both get MVPs live quickly. Our Firebase vs Supabase article compares them in detail, including what migrating later costs.
Can Supabase handle complex business logic?
Up to a point. Postgres functions, triggers and Edge Functions cover a lot, including webhooks, price checks and notifications. When logic becomes long-running or integration-heavy, such as multi-step payouts or ERP sync, we add a separate API service that reads the same Postgres database. That keeps Supabase for what it does well without forcing everything into it.
Who owns the Supabase project and data?
You do. The project sits in your own Supabase organisation with your billing, and we work through access you grant and can remove. Schema and policies live as migrations in your repository, and an NDA is signed before discovery. Because the data is standard Postgres, you can export it or move it at any time.
Launch on Supabase with security done properly
Book a 30-minute scoping call. We will look at your data model and features and tell you whether Supabase fits, how we would set up RLS and when you might need a custom API beside it.