Supabase VPS Requirements: RAM, CPU and Storage (2026)

Last verified: 25 October 2026

The current official minimum for the complete self-hosted Supabase stack is 4 GB RAM, 2 CPU cores and 40 GB of SSD storage. Supabase recommends 8 GB or more RAM, 4 or more cores and at least 80 GB SSD.

Those figures are a deployment envelope, not a promise about users, requests or database size. A 4 GB server may complete the installation and still have too little headroom for a production import, backup, image transformation or traffic spike. Size the VPS from the services you enable and the work they perform.

Supabase VPS requirements at a glance

Deployment	RAM	CPU	SSD	How to use the figure
Official minimum for all components	4 GB	2 cores	40 GB	Installation floor for evaluation or a constrained private project
Official recommendation	8 GB or more	4 cores or more	80 GB or more	Safer starting envelope for a small production deployment
Realtime, Storage, image or Edge-heavy workload	More than the recommendation may be needed	Measure sustained CPU and latency	Model database, objects, logs and free space separately	Load-test the actual application before committing to a tier

Supabase also documents that removing services such as Realtime, Storage, imgproxy or Edge Runtime can reduce resource demand. That is useful for a deliberately narrow deployment, but disabling a service only to fit a smaller VPS is a product decision. Confirm that the application does not depend on it.

The source for the two published resource tiers is Supabase’s current self-hosting with Docker guide, checked on 25 October 2026.

Why a Supabase server needs more than PostgreSQL

The self-hosted Docker deployment is a group of cooperating services. PostgreSQL is central, but authentication, REST access, Realtime, Storage, the API gateway, Studio, connection pooling and optional Edge functions also need memory, CPU time and disk access.

That changes the sizing question. Do not compare the official 4 GB minimum with the memory use of an empty PostgreSQL process. The complete server also needs room for:

the operating system and Docker;
the database cache, connections, queries and maintenance work;
authentication, API and Realtime services;
Storage metadata and object traffic when Storage is enabled;
imgproxy work when images are transformed;
Studio, connection pooling and the API gateway;
logs, monitoring and any optional analytics services;
upgrades, imports, backups and other temporary peak work.

If another application shares the VPS, add its database, workers and peak jobs to the same budget. A server that looks idle most of the day can still fail during simultaneous backup, import and image-processing work.

A practical sizing method

The following tiers are editorial planning points based on the official resource envelope. They are not benchmark results and do not predict a fixed number of users.

Evaluation or private development

Use the official minimum only when the project is disposable or the workload is light enough that interruptions are acceptable. Keep the full 40 GB SSD floor, enable only required services and watch memory pressure, free space and container restarts.

A smaller custom deployment may work after removing services, but it is no longer the published full-stack minimum. Document what was removed so a later application change does not silently depend on a missing component.

Small production deployment

Start from the official recommendation of at least 8 GB RAM, 4 cores and 80 GB SSD. This gives more room for the database, application services and short peaks, but it is still only a starting point.

Before launch, test the real schema and workload. Include representative API requests, concurrent database connections, Realtime subscriptions, file uploads, image transformations, imports and a backup. Record memory, swap, CPU saturation, disk latency, database connections, request latency and free-space growth.

Data, media or Realtime-heavy deployment

Move beyond the recommended tier when one of these becomes sustained:

large imports or expensive PostgreSQL queries;
many concurrent connections or Realtime subscriptions;
frequent Storage uploads and downloads;
image transformation through imgproxy;
Edge functions with meaningful CPU or memory demand;
rapid database, object or log growth;
strict latency or recovery-time targets.

At that point, the next useful step may be faster or dedicated CPU, more memory, separate storage or a different operating model. Adding cores without checking database and disk behavior can leave the real bottleneck unchanged.

Shared CPU or dedicated CPU?

Shared CPU is usually the economical choice for evaluation and light, bursty use. The tradeoff is contention: neighboring workloads may use the same physical CPU capacity. A vCPU count alone therefore does not describe predictable database performance.

Dedicated CPU is easier to justify when PostgreSQL is continuously busy, request latency matters, or Realtime, image processing and background work create sustained load. Hetzner, DigitalOcean and Akamai Cloud all document a distinction between shared and dedicated CPU products. Contabo and Vultr also separate product families with different resource models.

Use observed CPU saturation and latency to decide. Do not assume that four shared vCPUs outperform two dedicated cores for every workload.

Storage and recovery are part of the server size

The SSD must hold more than the initial database. Plan capacity for database growth, indexes, write-ahead logs, temporary queries, Storage objects when kept locally, container data, logs, operating-system updates and enough free space to perform maintenance safely.

Keep the database and Storage growth models separate. A project with a small relational database can still accumulate a large object library. If either moves to attached block storage, verify how snapshots, backups and restores cover that volume.

Supabase’s self-hosting update guide says its update script backs up configuration but does not back up PostgreSQL or Storage data. Before an update, make an independent database backup and protect stored objects separately.

A recoverable plan includes:

a PostgreSQL backup that can be restored to a clean deployment;
a separate copy of Storage objects;
configuration and secrets stored securely outside the server;
a record of enabled services and version changes;
a restore test that measures whether the recovery time is acceptable.

Provider snapshots can shorten recovery, but they are not automatically complete or independent. Hetzner, DigitalOcean, Vultr and Akamai Cloud state that their server backup products exclude attached block storage. Contabo distinguishes its snapshots from backups and documents separate backup products for eligible VPS plans.

Production responsibilities people underestimate

Self-hosting transfers more than the hosting bill. Supabase’s self-hosting responsibility guide assigns server maintenance, security hardening, service configuration, database maintenance, backups, disaster recovery, monitoring, scaling and uptime to the operator.

Before public launch:

replace every default credential and secret;
configure a production-ready SMTP service for authentication email;
put the public endpoints behind HTTPS through a reverse proxy;
expose only required ports;
patch the operating system, Docker images and Supabase services on a schedule;
alert on downtime, memory pressure, disk exhaustion and certificate expiry;
rehearse an update and a full restore.

Docker’s Ubuntu installation guide contains an important firewall warning: ports published by Docker can bypass rules created with UFW or firewalld. Do not expose PostgreSQL or an internal dashboard because a host firewall appears to block it. Publish only required ports and verify the result from outside the VPS.

Which VPS provider fits the deployment?

The table is not a ranking. It identifies current operating differences that matter for Supabase. Check the selected region, resource model, storage, backup scope, traffic and current checkout total before ordering.

Provider	When it may fit	Verify before checkout
Contabo	Large fixed resource bundles are more important than fine-grained resizing	Current Core, Performance and Storage VPS differences, shared vCPU behavior, snapshot eligibility and whether the selected family supports Auto Backup
Hetzner	You want a clear choice between shared and dedicated CPU and may attach a Cloud Volume	Product availability by region and the fact that server Backups and Snapshots do not include attached Volumes
DigitalOcean	You want documented shared and dedicated CPU plans plus a control-panel resize path	Droplet type, irreversible disk increases and separate protection for Volumes because Droplet Backups exclude them
Vultr	Region choice and multiple compute classes are central to the decision	Whether the selected class uses shared resources and that automated backups exclude attached Block Storage
Akamai Cloud	You want Linode compute with documented shared and dedicated CPU plans	Plan and region support for the Backup Service, its same-data-center boundary and the exclusion of Block Storage Volumes

Official provider details: Contabo VPS documentation, Contabo Auto Backup, Hetzner CPU FAQ, Hetzner Volumes, DigitalOcean plan selection, DigitalOcean Backup limits, Vultr Cloud Compute, Vultr Backups, Akamai shared and dedicated CPU and Akamai Backup Service FAQ.

Current provider destinations

The following are affiliate links. We may receive a commission if you buy through them, at no extra cost to you. Their order is not a performance ranking, and the links do not change the requirements above.

A buying checklist for Supabase

Choose managed or self-hosted based on who will own updates, security and recovery.
Start from Supabase’s current full-stack requirement, not an old third-party minimum.
List the services the application actually uses before removing any container.
Estimate database, object and log growth separately.
Decide whether shared CPU is acceptable for the workload and latency target.
Confirm whether provider backups cover every disk and attached volume.
Build an off-account database and Storage backup, then test a restore.
Verify SMTP, HTTPS, secret replacement, exposed ports and monitoring before launch.
Load-test the actual schema and peak jobs, then resize from measurements.
Recheck current provider terms at checkout instead of relying on a copied price table.

Once the capacity and operating model are decided, continue with the Supabase installation guide for a VPS. The full VPS comparison covers a wider provider set, but no provider choice removes the need for application-level backups and monitoring.

Sources and review method

This guide was substantively reviewed on 25 October 2026 against current official Supabase, Docker, Contabo, Hetzner, DigitalOcean, Vultr and Akamai Cloud documentation. It is a documentation-based decision guide. No hands-on performance, uptime or support-response test is claimed.

Frequently asked questions

What are the official minimum VPS requirements for Supabase?

Supabase currently lists 4 GB RAM, 2 CPU cores and 40 GB SSD as the minimum for all components in its self-hosted Docker deployment. Treat this as an installation floor, not as a production capacity guarantee. Traffic, database size, enabled services and background work determine the useful capacity.

Is 4 GB RAM enough for a self-hosted Supabase server?

Four gigabytes matches the current official minimum for the complete stack, but it leaves limited operating headroom. For a small production deployment, the official recommended starting point of 8 GB or more is more defensible. Measure memory during imports, backups, image processing and peak requests before deciding.

Can Supabase run on a shared CPU VPS?

A shared CPU VPS can suit evaluation and light, bursty use. A busy PostgreSQL database, sustained Realtime traffic, image processing or latency-sensitive production workload is a stronger candidate for dedicated CPU. Provider vCPU counts are not directly comparable unless the sharing model is also known.

What must a Supabase backup include?

Protect PostgreSQL data, Storage objects, configuration, secrets and any attached volume separately. Supabase states that its update script does not back up PostgreSQL or Storage data. Provider server backups also commonly exclude attached block storage, so keep an independent copy and test a clean restore.

Should I self-host Supabase or use the managed service?

Self-host when control or deployment constraints justify owning operating-system maintenance, security, upgrades, PostgreSQL operations, backups, monitoring and recovery. Choose the managed service when those operational jobs would distract from the application or when the team cannot safely recover an outage.