- Who is this for?
- Supabase teams, agencies and developers evaluating PostgreSQL backends.
- Before you start
- A project inventory, used Supabase services, data sizes and a named operations owner.
1. Understand the current invoice
Separate project compute, metered usage and optional features. Identify production projects and unused development environments. Keeping a test project running and creating a project for every customer produce different cost drivers. Review usage before changing a plan; a spend cap should not be read as a guarantee that every invoice component is fixed. Combining environments can reduce a line item while weakening data isolation.
2. Distinguish PostgreSQL from the complete stack
An app using only SQL has a different migration scope from one using Auth, Storage, Realtime and Edge Functions. Installing PostgreSQL on a server does not replace every Supabase feature. Inventory SDK calls and their backing services. A small VPS should not be assumed to run the complete stack adequately without a representative workload test.
| Dependency | Behavior to preserve |
|---|---|
| PostgreSQL | Schema, indexes, extensions and connection limits |
| Auth / RLS | Identity lifecycle and per-user access |
| Storage | Object policies and metadata |
| Realtime | Subscription permissions and reconnection |
3. Assign and price operational work
The team must own upgrades, security, monitoring, capacity and recovery. Record who performs each task, how much time it consumes and who covers absences. A quick first installation does not establish the cost of ongoing operation. Treat recurring maintenance separately from migration work and external service charges.
- Define database and object recovery independently.
- Test upgrades in staging with a rollback plan.
- Route disk, connection and error alerts to an owner.
- Keep recovery copies outside the failure domain being protected.
4. Compare an illustrative total budget
Using the planned 349 TRY Developer package plus 100 TRY of external services and 200 TRY of maintenance gives 649 TRY per month. Against a user-entered 1,000 TRY baseline, the difference is 351 TRY. These are illustrative inputs, not Supabase prices or measured savings. A lower baseline can make the replacement more expensive.
Monthly budget = resources + external services + maintenance
Migration = data transfer + code changes + tests + engineering time5. Include permissions and rollback in the pilot
Test RLS and cross-user access in the target environment. Privileged server credentials do not belong in a mobile bundle. A different database role can change the behavior of the same query. Verify identities, relationships and files together rather than accepting matching table counts. Retain the old path for the agreed recovery window and define who authorizes cutover.
6. Choose around ownership and scope
Cloud can suit teams prioritizing reduced operations work and integrated services. Self-hosting needs an operations owner, measured capacity and an explicit maintenance plan. If SQL is the only dependency, independent PostgreSQL behind an API is a narrower option. Compare all three against the same security, latency and recovery requirements, and document assumptions that still require a pilot.
Action summary
- Separate the database from the full platform.
- Price maintenance and recovery responsibilities.
- Validate permissions, identity and files together.
Common questions
Is self-hosting always cheaper?
No. Scope, external services, resource requirements and engineering time determine the result.
Can a 2 GB server run the entire stack?
No capacity guarantee follows from memory size alone. Test the selected services and representative concurrent load.
Sources and scope
Technical references are listed below. Examples illustrate implementation in your own environment; they are not customer benchmarks or claims of live Uygulama Cloud services. Check the current provider documentation before applying settings.
Sources checked: