Supastarter vs BoringPush: Locked to Supabase?

"Supabase starter" means two different things

Supastarter (by Sidi Dev) is built around Supabase: Auth, Postgres, storage, and realtime from one dashboard, one bill, one mental model. That depth is the whole pitch — and the whole lock-in question.

BoringPush treats Supabase as one of three equal engines behind a single database switch. Same word on both boxes, opposite philosophies underneath. This page sells BoringPush and admits where Supastarter wins — prices flagged verify-current throughout.

Head-to-head: 10 rows

Losses, plainly: if Supabase is your forever home, Supastarter's depth beats our breadth — tighter Auth integration, storage that just works, tutorials written for exactly your stack.

BoringPush wins the day you want out (or never want in): start SQLite at $0, flip to Supabase with zero query rewrites when you earn it, flip back if bills bite. Ship from anywhere on a Next.js stack where the database is a deployment detail — that row is the company, and no Supabase-native kit can match it without ceasing to be one.

The one they all miss: analytics built in, $0 forever

Supastarter ships no analytics. You bring PostHog, Mixpanel, or Plausible — and you pay their bill from month one.

BoringPush ships analytics in the box: event tables in your SQLite, SQL answers, CSV export for investors, and a cookie-free mode built in. No third-party account, no subscription that compounds while revenue doesn't.

The numbers behind "Bring your own":

• PostHog free tier ends at ~40k events/month → $450+/year
• Cookie consent banners bounce double-digit EU percentages before content loads
• Revenue attribution ("which source converted trial→paid?") requires export-merge pipelines from siloed tools vs a single SQL query when events live in your database

That gap is invisible on both landing pages. It shows up on your credit card and in your conversion rate.

Committing to Supabase for years, love one-dashboard everything? Supastarter, genuinely. Want the optionality — SQLite now, Postgres later, VPS bills always?

That's the left column. Either way verify current pricing and trial the auth flow first: whichever login you can wire in an afternoon predicts the whole relationship.

The lock-in test: price your exit before you enter

Every ecosystem pitch deserves one skeptical afternoon. Write down the exit before you need it:

1. Auth exit. Supabase Auth users live in auth.users — exportable, but password hashes use bcrypt (portable) while OAuth identities re-link per provider. Budget a day plus a "reconnect Google" email to users. Our provider-agnostic sessions move as config, not migration.
2. Storage exit. Objects download cleanly; the pain is URL rewrites across every record referencing Supabase paths. Count those references now (SELECT count(*)) — that number is your exit invoice in rows.
3. RLS exit. Row-level policies don't translate — they're Postgres-and-Supabase-shaped logic. Document each policy's intent in plain English as you write it; future-you (on any stack) will pay for that paragraph.
4. Bill exit. Model 10x current usage on both bills. If Supabase 10x still beats VPS-plus-time, commit happily — that's a decision, not a default.

Run the test, file it with your architecture notes, then choose freely. Lock-in you priced is called strategy; lock-in you discover is called regret.

The hybrid almost nobody considers

Supabase Auth plus everything else elsewhere. It's a legitimate shape: keep the best-in-class managed auth (passwordless, OAuth, row policies on user tables) while the app, billing webhooks, and analytics live on your VPS against SQLite. You pay Supabase's auth bill only, dodge the storage/egress meters, and keep the exit trivial because nothing else is coupled.

BoringPush supports exactly this split — point auth at Supabase and use SQLite for product data. Purists on both sides will object, which is usually a sign the compromise is priced right — and reversible in an afternoon either way.

FAQ

Can I use Supabase with BoringPush at all?

Yes — first-class: choose Supabase as the database, add the URL and keys, and run one schema file. Auth, queries, and webhooks work identically; only the engine changes.

Isn't switching databases later a fantasy? Nobody does it.

Teams do it constantly — usually away from a bill, toward Postgres, under deadline. That's exactly when zero-rewrite parity pays: the migration is config, not a sprint.

Which has better Supabase Auth integration?

Supastarter, by design — it's the center of their universe. Ours is provider-agnostic by design. Depth vs breadth, pick your religion.

What about Supabase storage vs R2/S3?

Supabase Storage is native inside the ecosystem and metered on egress. R2/S3 direct uploads bypass your server entirely with zero egress fees on R2. Convenience vs cost — same tradeoff as everything here.

Can I start Supastarter and move to BoringPush?

Yes: Postgres schema ports directly (same relational model), routes copy over a weekend, then decide about VPS when the meters say so.