If you need a single-binary backend that runs on a compact 1 GB RAM VPS, PocketBase is purpose-built for speed and simplicity. If you want a batteries-included Docker BaaS with native mobile SDKs, built-in push notifications, and 30+ serverless function runtimes, Appwrite is the strongest all-in-one contender. And if your team prefers end-to-end reactive TypeScript queries over writing SQL and Row-Level Security (RLS) policies, Convex offers a modern managed experience. In this guide, we compare the seven best managed and self-hosted backends so you can match your database model, licensing rules, and hosting budget to the right stack.

Why Developers Look for Supabase Alternatives

Supabase combines PostgreSQL with PostgREST, GoTrue authentication, Realtime WebSockets, S3-compatible storage, and Deno Edge Functions. As we covered in our step-by-step tutorial on how to self-host Supabase on a VPS with Docker and HTTPS, that modular design is powerful—but it also introduces trade-offs that prompt engineering teams to evaluate Supabase alternatives:

• Multi-container self-hosting overhead: Because Supabase stitches together more than a dozen distinct microservices behind a Kong API gateway, self-hosting it requires at least 4 GB of RAM (and 8 GB for production workloads). Teams building lightweight SaaS micro-tools or internal dashboards often prefer a single binary or a leaner container stack.
• Per-project cloud pricing and pausing limits: On managed Supabase Cloud, free-tier projects pause after seven days of inactivity, and running multiple isolated staging, preview, and production environments on paid plans requires per-instance compute add-ons plus usage billing for Monthly Active Users (MAUs) and egress bandwidth.
• SQL and Row-Level Security (RLS) complexity: Exposing PostgreSQL tables directly to client browsers via PostgREST means your application security depends on writing airtight SQL RLS policies. Some teams prefer enforcing authorization inside server-side TypeScript functions or unified SDK middleware rather than database policies.
• GraphQL or non-PostgreSQL requirements: While Supabase offers the pg_graphql extension, teams building complex Apollo or Relay frontends frequently want a native Hasura GraphQL workflow with server-side event triggers, or an abstraction layer that works over existing MySQL, MariaDB, or SQLite databases.

Quick Comparison: Top 7 Supabase Alternatives

Before diving into individual architectures, use the comparison matrix below to see how the leading managed and self-hosted Supabase alternatives differ by underlying database engine, open-source license, and primary strength.

Managed Cloud BaaS vs Self-Hosted VPS Backends

When evaluating backend platforms, the most consequential decision is not whether your API speaks REST or GraphQL—it is where your data lives and how your infrastructure scales financially. Backend platforms fall into two operational models: vendor-managed cloud services and self-hosted open-source backends running on a VPS.

Managed cloud backends (such as Firebase, Convex Cloud, and Neon) handle operating system patching, multi-region replication, and automated point-in-time backups. They are ideal when your engineering team wants zero infrastructure maintenance during rapid prototyping. However, managed clouds meter every dimension of growth—charging per Monthly Active User (MAU), per million document reads or function invocations, per gigabyte of storage, and per gigabyte of outbound bandwidth.

Self-hosted open-source backends (such as Appwrite, PocketBase, Directus, Nhost, and self-hosted Supabase) run on your own virtual private server. Instead of paying per user or per API call, you pay a flat, predictable monthly fee for CPU cores, RAM, and NVMe/SSD storage on a self-managed Linux VPS or a Ghana Virtual Dedicated Server (VDS). Whether your application serves 500 registered users or 250,000 users, your software licensing cost remains zero and your data stays under your direct jurisdiction.

Best Self-Hosted Open-Source Supabase Alternatives

If your priority is full infrastructure control, data residency compliance, and predictable hosting bills on a Linux VPS, these four open-source platforms are the strongest Supabase alternatives available today.

1. Appwrite: Best All-in-One Docker BaaS

Appwrite (licensed under BSD 3-Clause) is the most comprehensive open-source alternative to both Supabase and Firebase. Rather than exposing raw SQL tables directly to client browsers, Appwrite provides a clean, unified abstraction layer with official SDKs for Web, Flutter, iOS/macOS, Android, React Native, Node.js, Python, PHP, Go, and .NET.

• Why choose Appwrite over Supabase: Appwrite includes native Messaging (email, SMS, and push notifications via APNs and FCM) and supports more than 30 serverless function runtimes (Node.js, Bun, Python, Dart, Go, PHP, Ruby, Rust, and .NET), whereas Supabase Edge Functions are limited to the Deno TypeScript/JavaScript runtime.
• Self-hosting experience: Appwrite ships with an interactive single-command Docker installer (docker run -it --rm ... appwrite/appwrite) that provisions MariaDB, Redis, background workers, and a built-in Traefik reverse proxy with automatic Let’s Encrypt SSL certificates.
• Trade-offs: Because Appwrite abstracts its underlying MariaDB storage behind a document-and-collection API, you cannot run arbitrary raw SQL joins or install custom PostgreSQL extensions like pgvector directly inside Appwrite’s primary database.

2. PocketBase: Best Lightweight Single-Binary Backend

PocketBase (MIT license) takes the opposite architectural approach to heavy multi-container stacks. Written in Go, the entire backend—including an embedded SQLite database running in Write-Ahead Logging (WAL) mode, user authentication, file storage, real-time Server-Sent Events (SSE), and a responsive Admin Dashboard UI—compiles into a single standalone executable file.

• Why choose PocketBase over Supabase: You can deploy PocketBase on an entry-level 1 vCPU, 1 GB or 2 GB RAM VPS without even installing Docker. A single binary idling at under 40 MB of RAM can handle over 10,000 concurrent real-time SSE connections. You can also extend PocketBase using built-in JavaScript hooks (pb_hooks) or import it as a Go library to compile your own custom binary.
• Self-hosting experience: Upload the binary to your Ubuntu VPS, create a 15-line systemd unit file, and either let PocketBase manage its own Let’s Encrypt TLS certificate on port 443 or proxy it behind Caddy. Backups are as simple as snapshotting the pb_data/ directory or using PocketBase’s built-in S3 backup scheduler.
• Trade-offs: Because SQLite is an embedded file database, PocketBase scales vertically on a single server rather than horizontally across multi-node read replicas.

3. Nhost: Best GraphQL-First PostgreSQL Alternative

Nhost (MIT license) is the closest architectural cousin to Supabase, built directly on standard PostgreSQL. The key difference is the API layer: while Supabase centers on PostgREST for RESTful table queries, Nhost pairs PostgreSQL with the Hasura GraphQL Engine, alongside Hasura Auth, S3-backed Hasura Storage, and Node.js serverless functions.

• Why choose Nhost over Supabase: If your frontend team uses GraphQL clients (Apollo, urql, or Relay), Nhost gives you instant real-time GraphQL queries, mutations, and subscriptions, plus Hasura’s visual role-based permission builder and webhook event triggers on database inserts/updates—eliminating the need to write raw SQL Row-Level Security policies by hand.
• Trade-offs: Hasura’s metadata engine consumes substantial memory, so self-hosting Nhost via Docker Compose requires at least 4 GB of RAM.

4. Directus: Best SQL-to-API Data Platform & Headless Studio

Directus (BSL 1.1, free to self-host for most small and mid-sized businesses) is an open-source data platform that wraps any new or existing SQL database—including PostgreSQL, MySQL, MariaDB, SQLite, CockroachDB, and MS SQL Server—with instant REST and GraphQL APIs plus a polished, non-technical Data Studio dashboard.

• Why choose Directus over Supabase: Supabase Studio is designed for developers, not content editors or operations staff. Directus provides a customizable, role-based back-office UI, visual automation Flows (webhooks, cron triggers, email notifications), and real-time WebSockets without modifying your existing SQL schema.
• Trade-offs: Directus is focused on data management, authentication, file transformations, and workflow automation rather than hosting arbitrary serverless edge compute.

Best Managed Cloud & Composable Supabase Alternatives

If your team prefers a managed cloud workflow or wants to compose a modular stack using best-of-breed serverless tools, these three platforms lead the market.

5. Convex: Best Reactive TypeScript Backend

Convex rethinks the backend by replacing SQL tables, ORMs, and manual WebSocket channels with a reactive document-relational database controlled entirely through server-side TypeScript functions. When you write a Convex query function in TypeScript, the platform automatically tracks its data dependencies and pushes live updates to your React, Next.js, Vue, or mobile client whenever the underlying records change.

• Why choose Convex over Supabase: Zero SQL migrations, zero RLS debugging, and automatic end-to-end TypeScript type safety. Every Convex mutation runs as a deterministic, serializable ACID transaction, and built-in primitives cover cron jobs, scheduled background functions, vector search, and file storage. While Convex is primarily used as a managed cloud service, its Rust/TypeScript backend engine is also open-source under FSL 1.1 for self-hosting on a VPS.

6. Neon + Dedicated Auth: Best Serverless Branching PostgreSQL

Many teams use Supabase strictly for managed PostgreSQL and authentication, ignoring PostgREST and Realtime in favor of server-side ORMs like Drizzle or Prisma inside Next.js, Remix, or Astro. For that architecture, Neon paired with Better Auth, Auth.js, or Clerk is often a cleaner fit.

• Why choose Neon over Supabase: Neon decouples PostgreSQL compute from storage, enabling instant copy-on-write database branching. Whenever a developer opens a GitHub pull request, your CI/CD pipeline can spin up an isolated branch containing a full copy of your production schema and data in less than a second, and scale compute down to zero when idle.

7. Google Firebase: Best for Offline-First Native Mobile Apps

Google Firebase remains the benchmark for native iOS, Android, and Flutter mobile apps that require seamless offline-first local caching and automatic background synchronization when a device regains connectivity. Combined with Firebase Cloud Messaging (FCM), Crashlytics, and Remote Config, it offers mobile lifecycle tooling that no PostgreSQL BaaS matches out of the box—at the cost of proprietary NoSQL vendor lock-in and zero self-hosting support.

VPS Sizing & Resource Requirements for Self-Hosted Backends

If you decide to self-host an open-source backend on a Linux server, resource consumption varies dramatically depending on whether the platform runs as a compiled Go binary, a single Node.js container, or a 12-container orchestration stack. Use the sizing table below when selecting your server plan.

How to Choose and Deploy Your Backend Architecture

To avoid costly mid-project migrations, match your backend choice to your team’s primary query model and operational capacity using this decision framework:

1. Need a fast, low-cost MVP, internal tool, or mobile backend on a small VPS? Deploy PocketBase as a systemd service behind Caddy. You get instant auth, real-time subscriptions, file uploads, and an admin UI using a fraction of the RAM required by Docker stacks.
2. Need an all-in-one self-hosted cloud replacement with mobile SDKs, push notifications, and multi-language functions? Provision a 4 GB to 8 GB RAM VPS and run the official Appwrite Docker installer.
3. Need full PostgreSQL power, extensions (pgvector, PostGIS), and compatibility with existing Supabase SDKs? Keep Supabase, but move off usage-metered cloud tiers by following our guide to self-hosting Supabase on a VPS with Docker and HTTPS.
4. Need an instant back-office dashboard and API over a clean SQL schema? Deploy Directus alongside PostgreSQL or MariaDB in Docker Compose.
5. Building an AI agent or automated customer support workflow? Pair your self-hosted PostgreSQL or PocketBase backend with an AI orchestration platform—see our tutorial on how to build an AI help desk with OpenClaw for a complete production blueprint.

If you are ready to deploy PocketBase, Appwrite, Directus, or a self-hosted PostgreSQL stack with predictable monthly pricing, explore our self-managed Linux VPS hosting for full root SSH access and high-speed SSD storage, or our Ghana VDS plans for dedicated CPU cores and local Accra NVMe storage. If you want help sizing your server or migrating an existing cloud database, contact the Aveshost team.

Frequently Asked Questions

Self-hosting Supabase gives you full ownership of your PostgreSQL 15 database, predictable monthly server costs, unrestricted database size up to your VPS disk capacity, and complete control over data residency—without losing the developer experience of Supabase Studio, GoTrue authentication, PostgREST auto-generated APIs, Realtime WebSockets, or S3-compatible Storage.

Key Takeaways

• Size your VPS for a 12-container stack: A production self-hosted Supabase instance runs PostgreSQL, Kong, GoTrue, PostgREST, Realtime, Storage, Supavisor, and Supabase Studio simultaneously—start with at least 4 GB RAM and 2 vCPU cores (8 GB RAM recommended for active production workloads).
• Never deploy with default .env.example keys: Every default JWT secret and database password in the public repository is publicly known. Always generate fresh cryptographic keys before starting the containers.
• Keep port 8000 bound to localhost: Docker’s port publishing bypasses standard UFW rules if bound to 0.0.0.0. Bind Kong to 127.0.0.1:8000:8000 and route all external traffic through an HTTPS reverse proxy on port 443.
• Enable WebSocket upgrades on your reverse proxy: Supabase Realtime requires HTTP/1.1 Upgrade and Connection headers so live database subscriptions work over wss://.

How to Self-Host Supabase on a VPS: Docker Architecture Overview

Unlike a standalone database container, Supabase’s official Docker setup is a complete backend-as-a-service platform built around PostgreSQL. When you self-host Supabase on a VPS, you do not expose seven different microservice ports to the internet. Instead, every external client SDK request and Studio dashboard session enters through a single reverse proxy on port 443, which forwards traffic to the internal Kong API Gateway (:8000).

Inside the private Docker bridge network, Kong routes each path to its dedicated container:

• /rest/v1/ → PostgREST: Introspects your PostgreSQL schema and exposes instant, Row-Level-Security (RLS) enforced REST endpoints.
• /auth/v1/ → GoTrue: Manages user sign-ups, JWT issuance, magic links, and OAuth logins.
• /realtime/v1/ → Supabase Realtime: Broadcasts PostgreSQL logical replication changes, presence, and broadcast messages over WebSockets.
• /storage/v1/ → Storage API & imgproxy: Handles file uploads, access control policies, and on-the-fly image resizing.
• / (Root) → Supabase Studio (:3000): Serves the web-based visual table editor, SQL workbench, and policy manager, protected by Kong Basic Auth.

VPS Hardware Requirements and Sizing Matrix

Because the Docker Compose bundle launches PostgreSQL, an Elixir virtual machine for Realtime, Kong, Vector log aggregation, Logflare analytics, Supavisor connection pooling, and the Node.js Studio interface, running on a 1 GB or 2 GB server will trigger Linux out-of-memory (OOM) kills. Use the sizing table below to select the right server tier on Aveshost Self-Managed VPS Hosting or Aveshost Ghana VDS:

Step 1: Provision Your Ubuntu VPS, DNS, and Firewall

Deploy a clean Ubuntu 22.04 LTS or 24.04 LTS server and point a dedicated subdomain—such as supabase.yourdomain.com or api.yourdomain.com—to your VPS public IPv4 address using an A record in your DNS manager (if you need a domain, register one via Aveshost Domains). If you proxy the subdomain through Cloudflare, set SSL/TLS encryption mode to Full (Strict) after completing Step 6, and make sure security rules do not inadvertently block verification challenges on your API endpoints.

Connect to your VPS over SSH, update system packages, create a 4 GB swap file (for resilience during container startup spikes), and configure UFW so only SSH (22), HTTP (80), and HTTPS (443) are open publicly:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl git ufw openssl ca-certificates

# Create a 4 GB swap file if none exists
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# Configure UFW firewall
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw --force enable

Step 2: Install Docker Engine and Docker Compose v2

Install the official Docker Engine and Docker Compose v2 plugin directly from Docker’s APT repository rather than Ubuntu’s older distribution packages:

curl -fsSL https://get.docker.com | sudo sh
sudo systemctl enable --now docker

# Verify Docker and Docker Compose v2
docker --version
docker compose version

Step 3: Clone the Official Supabase Docker Stack

The main Supabase monorepo is large, so use a shallow clone to download only the latest commit, copy the docker/ deployment folder to /opt/supabase, and create your working .env file from .env.example:

sudo mkdir -p /opt/supabase
cd /opt
sudo git clone --depth 1 https://github.com/supabase/supabase.git supabase-repo
sudo cp -rf /opt/supabase-repo/docker/* /opt/supabase/
sudo cp /opt/supabase-repo/docker/.env.example /opt/supabase/.env
sudo rm -rf /opt/supabase-repo
cd /opt/supabase

Step 4: Generate Cryptographic Secrets and Configure .env

Before starting the containers, you must replace the placeholder credentials in /opt/supabase/.env. Every service in the cluster relies on these core variables:

Run the official key-generation helper included in /opt/supabase (or generate secrets with OpenSSL):

cd /opt/supabase
# Option A: Run Supabase's built-in secret generator script
sudo bash ./utils/generate-keys.sh

# Option B: Generate clean alphanumeric secrets manually if needed
openssl rand -hex 24   # Use for POSTGRES_PASSWORD and DASHBOARD_PASSWORD
openssl rand -hex 32   # Use for JWT_SECRET and SECRET_KEY_BASE
openssl rand -hex 16   # Use for VAULT_ENC_KEY (32 hex chars)

Next, open /opt/supabase/.env (sudo nano /opt/supabase/.env) and set your public HTTPS domain and transactional email settings (if you need a free transactional relay for testing auth emails, see our guide on how to use the Gmail SMTP server):

SITE_URL=https://app.yourdomain.com
API_EXTERNAL_URL=https://supabase.yourdomain.com
SUPABASE_PUBLIC_URL=https://supabase.yourdomain.com

DASHBOARD_USERNAME=avesadmin
DASHBOARD_PASSWORD=YourStrongDashboardPasswordHere

SMTP_ADMIN_EMAIL=admin@yourdomain.com
SMTP_HOST=smtp.yourdomain.com
SMTP_PORT=587
SMTP_USER=smtp-user@yourdomain.com
SMTP_PASS=YourSmtpPassword
SMTP_SENDER_NAME=YourApp

Step 5: Lock Down Local Ports and Launch the Containers

By default, Docker’s port mapping (8000:8000) binds to 0.0.0.0 and manipulates iptables directly, which exposes unencrypted HTTP port 8000 to the public internet even when UFW is enabled. To prevent anyone from bypassing your HTTPS reverse proxy, bind Kong’s ports to 127.0.0.1 inside /opt/supabase/docker-compose.yml:

# Inside /opt/supabase/docker-compose.yml under the kong service:
    ports:
      - 127.0.0.1:8000:8000/tcp
      - 127.0.0.1:8443:8443/tcp

Now pull the container images and launch the stack in detached mode:

cd /opt/supabase
sudo docker compose pull
sudo docker compose up -d

# Check that all services report "healthy"
sudo docker compose ps

Verify locally that Kong responds on port 8000 by running curl -I http://127.0.0.1:8000 (it should return an HTTP 401 Unauthorized prompt from Kong’s Basic Auth gate protecting Studio).

Step 6: Enable Automated HTTPS with Caddy or Nginx

To serve your Supabase Studio dashboard and client APIs (https://supabase.yourdomain.com) over TLS with automatic certificate renewal and full WebSocket (wss://) support, install Caddy (the simplest single-file option) or Nginx + Certbot.

Option A: Caddy Reverse Proxy (Automatic Let’s Encrypt SSL)

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

Replace /etc/caddy/Caddyfile with the following configuration (replace supabase.yourdomain.com with your actual subdomain):

supabase.yourdomain.com {
    encode zstd gzip
    reverse_proxy 127.0.0.1:8000
}

Reload Caddy (sudo systemctl reload caddy). Caddy automatically provisions a Let’s Encrypt TLS certificate, redirects HTTP to HTTPS, and forwards WebSocket upgrades to Kong (127.0.0.1:8000).

Option B: Nginx + Certbot (With WebSocket Upgrade Headers)

If your server already runs Nginx, make sure your server block includes Upgrade and Connection headers so Supabase Realtime WebSockets work properly, then run sudo certbot --nginx -d supabase.yourdomain.com:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    server_name supabase.yourdomain.com;
    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 86400;
    }
}

You can now open https://supabase.yourdomain.com in your browser, sign in with your DASHBOARD_USERNAME and DASHBOARD_PASSWORD, and connect your frontend or backend apps using:

import { createClient } from '@supabase/supabase-js'

const supabase = createClient(
  'https://supabase.yourdomain.com',
  process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY
)

Production Hardening, Backups, and Safe Upgrades

• Automate Nightly PostgreSQL Backups: Schedule a cron job that runs docker exec supabase-db pg_dumpall -U postgres | gzip > /backups/supabase.sql.gz and syncs encrypted archives to off-site object storage.
• Enable Row Level Security (RLS) on Every Public Table: Because the ANON_KEY is embedded in browser and mobile apps, any table in the public schema without RLS enabled is readable and writable by anyone with your URL and anon key.
• Restrict Studio Access by IP (Optional): For high-security environments, restrict the Studio dashboard path in Caddy or Nginx to your office VPN IP while leaving /rest/v1/, /auth/v1/, /realtime/v1/, and /storage/v1/ open to public client apps.

Ready to deploy your own high-performance Supabase cluster? Launch an Ubuntu server on Aveshost Self-Managed VPS Hosting for full root control, choose Aveshost Ghana VDS for dedicated local NVMe performance, or select Aveshost Fully Managed VPS Hosting if you want our engineering team to handle server administration, firewall hardening, and monitoring for you.

Frequently Asked Questions