Self-Hosting My Backend (Supabase vs Appwrite)

Devlog – Self-Hosting My Backend (Supabase vs Appwrite)


I recently tried self-hosting Supabase on my VPS for my upcoming app idea. My goal was to find something like Firebase but more affordable, and Supabase looked like the right fit.

🚧 First Attempt: Supabase with Docker

I cloned the Supabase project from GitHub, edited the .env file, and started it up with Docker. At first, everything seemed fine—but once I opened the Supabase Studio dashboard, I was hit with Postgres errors.

At first, I thought this was just a password mismatch problem. Here are the steps I took to try and fix it:

1. Editing the .env file

I updated the database-related parameters in .env

Following the guide from supabase docs, I generated a JWT accordingly and updated it in .env, additionally changed the default passwords for database and dashboard to stay protected.
I expected Supabase to pick up these changes when restarting the containers, but it didn’t.

2. Changing the password inside the container

Next, I decided to directly modify the password inside the running Postgres container.

docker exec -it supabase_db bash
psql -U postgres

Inside the Postgres CLI, I ran:

ALTER USER supabase_admin WITH PASSWORD 'newpassword123';
\q

After exiting, I restarted all the containers, but the errors persisted.

3. Full cleanup and reset attempts

I thought maybe the old configs or data were sticking around, so I tried:

  • Cleaning Docker completely: 
    docker system prune -a --volumes
  • Manually deleting volumes and data directories: 
    rm -rf ./volumes/db/data
  • Removing all containers and starting fresh with docker-compose up -d

Even after a completely fresh start, the same Postgres errors came back.

4. The resource problem

On top of the errors, I noticed that a process called beam.smp was consuming a lot of RAM—way more than my VPS could handle. This made me realize Supabase might simply be too heavy for my current setup. 

🧩 What is beam.smp?

  • beam.smp is the Erlang virtual machine (VM) process.

  • It’s what runs Elixir and Erlang-based applications.

  • In Supabase’s case, it comes from Elixir services (like Realtime, which handles database change streams, subscriptions, and live updates).

So when you self-host Supabase, some of its components (like supabase/realtime) run on the Erlang VM, and that’s why you see beam.smp consuming memory.

⚠️ Why does it use so much RAM?

  • The Erlang VM is designed for high-concurrency systems (like chat servers, pub/sub messaging, live updates).

  • It keeps a lot of processes alive and optimizes for scalability rather than minimal memory usage.

  • On a small VPS (with 1–2 GB of RAM), this overhead becomes noticeable — especially combined with Postgres + API + Studio.

 

🔄 Switching to Appwrite

At this point, I looked for alternatives and found Appwrite. It had the same Firebase-like features I needed and even came with a one-line Docker setup.

I ran:

docker run -it --rm \
  --volume /var/run/docker.sock:/var/run/docker.sock \
  appwrite/appwrite install

It worked instantly and used much less RAM than Supabase.

However, when I tried registering in the Appwrite dashboard, I got hit with an “Unknown Origin” error. After digging into the logs, I realized the issue was with the APP_DOMAIN variable inside the .env file not being configured properly.

To fix this, I stopped the one-liner containers and restarted Appwrite using its docker-compose.yml setup so I could easily edit configs.

⚙️ The Real Culprit: Apache Config

Even after fixing the APP_DOMAIN, the “Unknown Origin” error persisted. After more investigation, I discovered the real issue: my Apache reverse proxy wasn’t passing the Host header correctly.

The fix was to add these two lines to my Apache config for the subdomain:

ProxyPreserveHost On
ProxyRequests Off

After reloading Apache, everything worked perfectly. 🎉

💡 Reflections

  • Supabase is powerful, but its resource usage makes it unsuitable for small VPS setups.
  • Appwrite is lighter and easier to deploy, though getting the proxy config right was crucial.
  • I learned that sometimes errors aren’t caused by the software itself, but by environment-level configurations like proxies or headers.

Comments

Post a Comment

Popular Posts