Build the Backend Your App Needs.Give Every Feature a Place to Run.

You get a preconfigured Supabase environment, not a finished application. Our plan listing includes PostgreSQL, Auth, Realtime, generated APIs, automated installation and dedicated support. The plans differ in CPU, memory, storage and bandwidth.

• Ready to configure: the Supabase services supplied with your plan.
• Yours to build: tables, access policies, app screens and integrations.

Compare the plan cards above for the current allocation and billing term.

Start with Pro for the published minimum; compare Business for more headroom. Supabase’s sizing guide lists 2 CPU cores and 4 GB RAM as the minimum for all components, with 4 cores and 8 GB or more recommended.

• Starter: 1 vCPU and 2 GB RAM, below that full-stack minimum.
• Pro: 2 vCPU and 4 GB RAM, matching the minimum.
• Business: 4 vCPU and 8 GB RAM, matching the recommended starting allocation.

Size for the services and traffic you expect, then test the workload before production.

No. This is a preconfigured self-hosted Supabase environment on Truehost. Supabase Cloud is the separate managed platform operated and billed by Supabase.

The standard self-hosted stack does not include Cloud features such as managed backups, point-in-time recovery or branching. If you use those features today, review the self-hosting differences before moving a project.

No. It gives your app a backend; you still build and host the frontend. For example, a customer portal can use Supabase Auth to sign users in and PostgreSQL to store orders, while your website or mobile app provides the screens customers see.

Connect the frontend only after you have defined the data model and access rules it needs.

Auth establishes who is making a request. Database grants and row-level security (RLS) determine what that person can do and which rows they can reach. Signing in does not automatically make customer records private.

1. Enable RLS on each table exposed to the app.
2. Grant only the operations each role needs and write policies for the permitted rows.
3. Test allowed and denied reads and writes with separate user accounts.

Follow Supabase’s RLS guide before exposing real data.

Use live subscriptions where they earn their cost. A shared support queue may need updates as colleagues change a ticket; a static account-settings page usually does not.

Start with the screens that need immediate change, then test the number of connected clients and the rate of database updates against your plan’s resources.

Supabase Storage supports file uploads when it is configured in the deployment. Keep public assets and private customer documents in appropriately controlled buckets, and set access policies before your app accepts uploads.

Our short plan listing does not specify the Storage setup. Confirm it for your chosen plan, along with file-size limits, available space and the backup arrangement for uploaded objects.

Our plan listing includes generated REST and GraphQL APIs, but your data is only ready to expose after you configure it. Create the schema, set database grants and RLS policies, then test queries as both a signed-in user and a visitor.

Confirm that the GraphQL service is enabled in your instance if your application depends on it. Keep privileged keys in trusted server-side code.

Do not assume backups or point-in-time recovery are included. Our public plan list does not state a backup schedule or point-in-time recovery. Supabase’s managed backup and PITR features are not part of the standard self-hosted stack.

Before storing production data, establish what is backed up, how often, where copies are kept and who tests a restore. Include uploaded files as well as the database.

Automated installation and dedicated support are listed; agree on the ongoing operating responsibilities for your plan. Confirm who applies Supabase and system updates, watches service health, responds to incidents and performs restores.

After an update, test sign-in, an API read and write, and any Realtime or Storage flow your app relies on.

Yes, but plan an application migration, not just a database copy. Supabase’s migration guide covers roles, schema and data, including Auth users. Other pieces need separate work:

• Transfer Storage objects and redeploy Edge Functions you use.
• Reconfigure secrets, email, sign-in providers and redirect URLs.
• Test a restored instance before changing your app’s endpoint; users may need to sign in again.

This plan is for the preconfigured Supabase environment. If you need to install and operate your own mix of applications alongside the backend, compare a standard VPS instead.

Choose the Supabase plan when a prepared backend is the job; choose a standard VPS when the whole server stack needs to be yours to assemble.