Postgres underneath. Discipline on top.
We are a senior Supabase development agency: we build, rescue, and run Supabase backends in production, for client platforms and for our own SaaS. Row-level security designed as a real boundary, backups that actually restore, and receipts you can click.
Six Supabase systems, all in production.
Most agencies claiming Supabase expertise can show you a demo. These are shipped platforms with published case studies on this site, including our own SaaS and the careers system live on this site right now.
Every claim above is pulled from the linked case study, not from this page. If a number is not in the case study, we do not print it here.
What we do with Supabase.
Eight areas, one standard: RLS treated as the security boundary, backups that restore, and code your own team can maintain after handover. Select an area.
New Supabase builds
Product builds where Supabase is the backend from day one: schema design, RLS as the security boundary, auth flows, edge functions, and a deploy pipeline. The same discipline we used to ship CleverCoach and our own PeoplePlus.
Everything ships with source, migrations under version control, and a runbook. You own the project; we make sure your team can run it without us.
What the pitch decks leave out.
Supabase is excellent, and it has operational edges that are documented but rarely read. None of this is a reason to avoid the platform. It is the difference between a project that survives its first bad day and one that does not. Facts current as of mid-2026.
Storage is not in the backups
Supabase's native backups and point-in-time recovery cover the Postgres database only. Objects in Storage buckets are excluded, and Supabase documents this officially. If your product stores user uploads, contracts, or media, the platform's backup story does not include them.
We sync every Storage bucket to an S3 bucket the client owns, on a schedule, with lifecycle rules. The object store gets its own recovery story instead of borrowing the database's.
The free tier has zero automatic backups
Projects on the free plan get no scheduled backups at all. Daily backups start on the paid tier, with retention measured in days. Teams regularly discover this after the incident, not before it.
No client of ours runs production on an unbacked-up tier. Minimum posture: paid plan, plus external scheduled dumps to client-owned storage, so retention is a decision rather than a default.
Point-in-time recovery is a paid add-on with real pricing
PITR is not included by default. As of mid-2026 it runs roughly $100 to $400 per month depending on the retention window you choose, on top of compute. It also still covers only the database, not Storage.
We size PITR to the client's actual recovery point objective instead of guessing: some products genuinely need minutes-level recovery, many are fine with dailies plus WAL archiving to their own bucket at lower cost.
A restore you have never run is not a backup
Backups fail silently in every stack, not just Supabase: wrong bucket permissions, expired credentials, dumps that stopped including a schema. The only backup that counts is one that has been restored, timed, and signed off.
Every production engagement includes a restore rehearsal: we restore into a scratch project, verify row counts and storage objects, and write down how long it took. Then we put the rehearsal on a calendar.
Production readiness on Supabase is not a plan tier. It is an external backup pipeline to storage you own, and a restore you have actually rehearsed.
When Supabase is the wrong choice.
We make money building on Supabase, which is exactly why you should hear us say where it does not fit. If your project lands in one of these, we will tell you in the first call and point you at the right architecture instead.
And one thing that is not on the list: fear of lock-in. Supabase is standard Postgres, so the exit is pg_dump plus a planned migration of Auth, Storage, and functions. We have scoped that path; it is work, not a trap.
Your data can never leave your network
If regulators or contracts require everything inside your own VPC, managed Supabase is off the table. Self-hosting the open-source stack is possible, but at that point the honest comparison is plain Postgres in your VPC with a conventional backend, and plain Postgres often wins it.
You need a mobile-first offline sync engine
Firestore's offline-first replication is genuinely good, and Supabase does not have an equivalent built in. If your product is a mobile app that must work seamlessly offline and reconcile later, that one requirement can decide the platform.
Your workload is not relational
High-volume event streams, time-series telemetry at scale, or graph-shaped data have better homes: ClickHouse, a time-series store, a graph database. Postgres can hold them for a while; it should not be the end state.
You already run a platform team on Postgres
If your organisation operates RDS or Cloud SQL with real database engineers, Supabase's convenience layer buys you less. The auth and API layers your team already owns may serve you better than adopting a second way to do the same thing.
You expect to outgrow a single Postgres instance soon
Supabase scales as far as one beefy Postgres deployment scales, which is much further than most products ever need. But if your roadmap credibly requires horizontal sharding across regions in the next year, design for that from the start instead of retrofitting.
Scoped, shipped, handed over.
No hourly meters. A discovery sprint produces a fixed quote; the work runs as milestones; you end up owning everything. The drivers of cost are the tenancy model, the number of edge functions and integrations, realtime surfaces, migration volume, and compliance needs.
One to two weeks. We read the schema, the policies, and the product plans, then produce a written scope with fixed-price milestones. For rescues, this is where the audit findings land.
The build or hardening runs as milestones with explicit deliverables and acceptance criteria. Migrations stay under version control; every new table ships with its policies and its tests.
Full source, runbooks, and a restore rehearsal you watched happen. Stay on retainer for ongoing development, or take the keys; either way the project is yours.
Common questions about Supabase development.
What teams ask before handing us a Supabase project, answered the way we answer them on calls.
Yes, with discipline. Under the branding it is managed Postgres plus auth, storage, realtime, and edge functions, and Postgres is as enterprise-proven as databases get. Production readiness comes from what you add around it: RLS designed as a real security boundary, external backups (native backups do not cover Storage), point-in-time recovery sized to your actual recovery objectives, and observability. We run our own SaaS, PeoplePlus, on Supabase with multi-tenant RLS isolation, and we ship client platforms on it in production.
No. As of mid-2026, Supabase's native backups and point-in-time recovery cover the Postgres database only; objects in Storage buckets are excluded, and Supabase documents this openly. The free tier has no automatic backups at all. For production clients we set up an external pipeline: scheduled database dumps plus a sync of every Storage bucket to an S3 bucket the client owns, and we rehearse the restore so recovery is a runbook, not a hope.
For most B2B and SaaS products, Supabase. The core difference is the database: Supabase is real Postgres with SQL, joins, row-level security, and full portability (you can dump the database and leave), while Firestore is a proprietary document store that shapes your data model around its query limits. Firebase still wins for mobile-first apps that lean on its offline sync and for teams deep in the Google ecosystem. If your data is relational, and business data almost always is, start with Postgres.
Supabase gives you Postgres plus auth, storage, auto-generated APIs, realtime, and edge functions on day one, which saves a small team months of undifferentiated backend work. A custom backend on RDS or Cloud SQL wins when you need everything inside your own VPC, deep control over the API layer, or infrastructure your platform team already operates. The good news: because Supabase is standard Postgres, choosing it is not a one-way door. We have designed systems on Supabase precisely because the exit path is a pg_dump away.
We price by outcome, not by the hour. A rescue and hardening engagement (RLS audit, auth review, backup pipeline, performance pass) is the smallest thing we sell and typically starts in the low five figures. A full product build on Supabase usually lands from the mid five figures, and platform-scale builds go beyond that. The drivers are the tenancy model (how many roles, how strict the isolation), the number of edge functions and third-party integrations, realtime surfaces, data migration volume, and compliance requirements. A short discovery sprint produces a fixed quote before any build work starts.
Both. New builds and rescues run as fixed-price milestones scoped from a discovery sprint, each with explicit deliverables and acceptance criteria. Platforms we have built or hardened can move onto an ongoing engineering retainer that covers new features, dependency and Postgres upgrades, RLS review for every new table, and backup restore rehearsals. Our own SaaS, PeoplePlus, is developed on the same continuous model, so the retainer discipline is one we live with ourselves.
Yes, in either direction. Moving off is tractable because the database is standard Postgres: pg_dump or logical replication carries the data to RDS, Cloud SQL, or self-hosted Postgres. The real work is in the platform services: replacing Supabase Auth (exporting users and password hashes, reissuing JWTs), rehoming Storage objects, rewriting realtime consumers, and porting edge functions to your new runtime. We scope all four explicitly. Migrations onto Supabase, from Firebase or from legacy custom backends, follow the same discipline in reverse.
A tenancy key on every table, policies written per role against JWT claims, and no table left unprotected: RLS as the security boundary, not a decoration. Then we prove it, with per-role integration tests that attempt cross-tenant reads and writes and must fail. PeoplePlus, our own SaaS, isolates every organisation's data this way with four permission levels; CleverCoach runs three JWT-authenticated roles over 13+ RLS-protected tables. Policies that are never tested are policies you do not actually have.
We deploy managed Supabase for production clients by default: the hosted platform's operational surface (upgrades, monitoring, failover) is most of what you are paying for. Self-hosting the open-source stack is possible and we will scope it when data residency genuinely requires it, but you inherit the ops burden for Postgres, Auth, Storage, and Realtime yourself. For most teams with residency constraints, the honest comparison is self-hosted Supabase vs plain Postgres in your VPC with a conventional backend, and we will tell you which one fits.
Your Supabase project, run like production.
New build, rescue, or migration: the first conversation is with an engineer who has shipped this stack, and it starts with your schema, not a slide deck.