Supastarter Locks You In. This Doesn't.

The bundle has fine print

Bundled Supabase starters sell coherence.

Auth, Postgres, storage, realtime.

One dashboard.

One bill.

One mental model.

Six months in, teams love the depth and fear it equally.

Every feature built wove deeper.

Row policies as business logic.

Storage URLs in every row.

Sessions shaped like Supabase and nothing else.

Then the egress line grows teeth. Moving means an auth migration, URL rewrites and policy translation. A quarter nobody budgeted, because "free tier" made the decision feel free.

The starter did not lock anyone in. Their own code did, following the starter's gravity.

Enjoy any bundle. Own your exits.

Depth without doors is a beautiful room you cannot leave.

Native or portable Supabase

Lock-in compounds silently. Three reasons.

Row policies become irreplaceable logic. They start as security and end as the only implementation of tier checks and ownership. App guards first, so the truth travels. Policies second, so enforcement stays native.

Every native shortcut mortgages the move. Client idioms inline. Realtime coupled. Storage paths baked in. Each saves an hour today and bills a week at exit. Portable actions cost minutes per feature.

Egress meters punish success. Storage and transfer scale with users, the direction you want, while billing against you per byte. Success should dilute costs, never multiply them.

What to do

Export users, the storage map and policy intents.

Export your users and tables, keyed by email. Count every reference to a Supabase storage path. That count is your exit invoice.

Write each row-level policy's intent in plain English. Policies can be rewritten from English. Never from a dialect.

Land on shared actions, with Supabase as engine one.

Start on Supabase inside BoringPush's database interface. It feels identical: the same dashboard comfort, the same queries working.

The gravity is the opposite. Every new feature is portable automatically, because the app talks to the shared actions and never to Supabase directly.

New code cannot deepen lock-in.

Flip engines when bills or needs say so.

When egress pain, tier math or geography becomes real, move the rows, change the database setting and check the counts.

Sessions can survive, because identity lives in your own user rows. Storage is already portable if it sits at your own addresses. Rehearse on staging every quarter, so the real move is checklist-driven.

Native or portable, year two

The cost

Shared actions cost upfront sameness. Three small pieces per entity, reviewed for identical behavior, which native shortcuts skip.

Priced against a migration quarter plus egress creep, that discipline buys cheaply what freedom sells dear.

BoringPush does not publish exit timings. Rehearse your own.

Know this first

Shared actions cost upfront sameness. Roughly an hour per entity.

BoringPush does not publish exit timings. Rehearse your own.

Why BoringPush is the way to do this

Use Supabase. Keep the exit.

BoringPush runs on Supabase as a first-class engine. New features stay portable because the app never talks to it directly.

Depth without doors, no more.

FAQ

Is this just anti-Supabase sentiment?

No. Supabase is excellent infrastructure, honestly priced for many.

The argument is against coupling, not against a vendor. Use Supabase inside portable seams and keep its advantages, such as the dashboard and managed Postgres, with none of the gravity.

How much slower is portable development than native?

Roughly an hour per entity for three small files plus a sameness review, compared with native's single-file speed. The tax is real and small. The payoff compounds with every feature and every future decision.

Should new projects start on SQLite or on Supabase inside the shared actions?

SQLite by default for zero setup, file speed and simple tests. Supabase when the bundle earns it: realtime needs, team familiarity or Auth depth on day one. Both are reversible, so decide on velocity, not fear.

What migrates hardest despite the seams?

Habits and dashboards, since table editors and log tails have no portable twin, and realtime subscriptions, which are transport-specific by nature. Data, files and guards move quickly. Fingers take a month.

Can I keep Supabase for data and use BoringPush's own sign-in?

Yes, that is a legitimate steady state. BoringPush's sign-in stores users in your Supabase tables, and the rest of the app does not care. Choose it on purpose, document why and revisit it yearly.

When is a native Supabase starter simply the better buy?

For committed Supabase shops with no exit intent, where coherence is worth more than optionality. Depth fully used beats doors never opened. Know whether you are certain or uncertain.

Keep reading

• Supastarter vs BoringPush: Locked to Supabase? — the head-to-head this guide acts on
• Switch Databases With One Line (Zero Rewrites) — the flip both posts rehearse
• Supabase Starter That Keeps Your Exit Open — the seamed setup this guide graduates to