Hey everyone, a few weeks ago I posted here looking for real app owners willing to let me review their Supabase backend for free, in exchange for filming the review for my YouTube channel. I got way more interest than expected, picked 3 projects, and now the reviews are done. Here's a quick summary of what I found across all three.

Project 1 — A language learning app

• The most-accessed table had been fully scanned over 5 million times — no index on the foreign key. I identified 13 missing indexes total.
• 15 indexes that existed but had never been used — dead weight slowing down every write.
• A core table was 241 MB for only ~15K rows because of AI embeddings stored inline. Every unindexed filter was reading through all 241 MB.
• Almost no Row Level Security. Only 2 content tables had any RLS policies at all.
• A CASCADE rule meant deleting a category would silently nuke every record under it — along with all related data across multiple tables.

Project 2 — A collaborative SaaS tool (~10K users)

• An RLS policy named to suggest read-only access to display names actually exposed every column in the users table — emails, subscription plans, account providers — to anonymous, unauthenticated visitors.
• The permission-check table had been sequentially scanned 774,000 times because every page load triggered 3 separate RLS checks instead of 1.
• Deleting a user account would leave orphaned data behind in some tables, and another table would actively block the deletion entirely.
• Database was at ~530 MB, already past the free plan's 500 MB limit, mostly from auth system tables.

Project 3 — A bilingual content directory

• A table with sensitive operational data was fully open to anonymous users — anyone on the internet could read, modify, or delete records without authentication.
• Authentication tokens were readable by unauthenticated visitors. Anyone could browse valid tokens and use them to access restricted areas.
• A permissions system existed but was completely bypassed by a broader RLS policy giving any logged-in user edit access to any record.
• The most common query had been scanned 500,000+ times with no index — 556 million rows read unnecessarily.
• 11 tables allowed any authenticated user to delete shared data.

Common patterns I saw across all 3 projects:

1. Missing indexes on foreign keys and common filters — every single project had this. Supabase doesn't auto-create indexes on foreign keys, and most devs don't think to add them manually.
2. RLS policies that are either missing or too permissive — the most dangerous issues in every review were security-related. One project had almost no RLS at all, and the other two had policies that accidentally exposed far more than intended.
3. Tables that have never been vacuumed — dead tuples accumulating silently.
4. Inconsistent timestamp formats — mixing timestamptz and timestamp across tables.
5. CASCADE rules that are either too aggressive or missing entirely — leading to either accidental data deletion or orphaned records.

I'm taking 3 more projects.

Same deal as before:

• I review your production Supabase database completely free — indexes, query performance, table structure, RLS policies, schema design, scalability, the works.
• You get a full written report with every finding prioritized and exact SQL fixes.
• The review gets filmed for YouTube. I can shout out your app or anonymize everything — your call. No real user data is ever shown.

What I'm looking for:

• A production database with real traffic (doesn't need to be massive)
• Ideally some tables with enough data to see meaningful EXPLAIN ANALYZE results

If you're interested, drop a comment or DM me. First 3 solid projects I'll take on. Happy to share the channel so you can see how the first reviews turned out.

If you’re building anything serious with Supabase, there will likely come a point where you want more control over your infrastructure.

That’s exactly what I walked through in my latest video: how to migrate your Supabase database from the hosted platform to your own server using Docker.

Here’s a clear breakdown of the process 👇(there is also the video version: https://youtu.be/ME3\_sT6b-Zs)

Why Migrate Off Hosted Supabase?

Hosted Supabase is great to get started. But as your project grows, you may want:

• More control over your data
• Lower long-term costs
• Custom infrastructure (VPS, Docker, etc.)
• Better scalability and flexibility

That’s where self-hosting comes in.

Step 1: Get Your Database Connection URL

Inside your Supabase project:

1. Go to Project Settings
2. Click Database
3. Copy your connection string
4. Replace the password placeholder with your actual DB password

This URL will be used to extract your data.

Step 2: Dump Your Database (Roles, Schema, Data)

Using the Supabase CLI, you’ll generate 3 key files:

• roles.sql → users, permissions, RLS
• schema.sql → tables, structure
• data.sql → actual data (usually the largest file)

Run the CLI commands to dump each part of your database locally.

👉 Make sure Docker is running — it’s required for the CLI to work properly.

As shown in the walkthrough, the result should look something like:

• Small roles file
• Medium schema file
• Large data file (can be 100MB+ depending on your DB)

Step 3: Prepare Your New Server

Before importing:

• Set up your VPS
• Deploy Supabase (e.g., via Docker / Coolify)
• Ensure your Postgres container is running

You should now have a fresh, empty database ready to receive your data.

Step 4: Transfer SQL Files to Your Server

Use scp (or any file transfer method) to send your .sql files to your VPS.

Then copy them into your Postgres container:

docker cp schema.sql <container_id>:/schema.sql
docker cp roles.sql <container_id>:/roles.sql
docker cp data.sql <container_id>:/data.sql

Step 5: Import Everything into Postgres

Now execute the files inside your container using psql:

1. Import schema
2. Import roles
3. Import data

Order matters.

Each step will prompt for your database password and execute inside the container.

Once done, your database will be fully restored.

Step 6: Verify Everything

After importing:

• Tables should be present
• Data should be populated
• Auth + users should exist
• Logs and metadata should be intact

At this point, your migration is complete.

Important Notes

• Data import time depends on your database size
• Always test on staging before production
• OAuth requires additional setup in self-hosted environments
• Keep your credentials secure (don’t hardcode them)

Final Thoughts

This process might look intimidating at first, but it’s actually very straightforward once you break it down:

1. Dump
2. Transfer
3. Import

That’s it.

If you’re serious about scaling or owning your infrastructure, this is a skill worth having.

Hey everyone — I run a YouTube channel focused on database engineering, Supabase, and backend optimization (self-hosting, indexing, partitioning, that kind of thing).

I want to do something a bit different for my next few videos: instead of working with demo databases, I want to review real production Supabase projects and walk through actual optimization opportunities — indexes, query performance, table structure, RLS policies, the works.

What I'm offering: I'll do a full backend review of your Supabase project completely free. No course pitch, no upsell, nothing. Just a genuine review where I go through your setup and flag anything that could be improved.

The only trade-off: The review will be filmed for YouTube. I'm happy to shout out your app (great exposure if you want it), or I can anonymize everything — hide table names, blur any sensitive data, etc. No real user data gets shown either way. Totally your call on how much or how little you want visible.

What I'm looking for:

• A production database with real traffic (doesn't need to be massive, just not a tutorial project)
• You're open to having the review recorded
• Ideally some tables with enough data that we can actually see meaningful EXPLAIN ANALYZE results and talk about indexing, normalization, partitioning opportunities, etc.

If you're interested, drop a comment or DM me. First 3 solid projects I'll take on. Happy to share my channel so you can see the kind of content I make before committing.