DEV Community: Russel Dsouza

Every Way to Run Postgres for Local Dev in 2026, Ranked by Weight

Russel Dsouza — Wed, 23 Sep 2026 05:54:51 +0000

"Just run Postgres locally" hides a real decision. In 2026 there are four genuinely different ways to do it, and they differ by two orders of magnitude in weight. Picking wrong doesn't break anything; it just quietly taxes every git clone, every CI run, and every laptop on the team for the life of the project.

Here they are, lightest to heaviest, with the honest trade-offs.

1. Embedded: PGlite (~3 MB)

The newest option and the lightest by far. PGlite is Postgres compiled to WebAssembly, packaged as a library. You don't start a database, you import one:

import { PGlite } from '@electric-sql/pglite'

const db = new PGlite()            // in-memory
// const db = new PGlite('./data') // or persisted to disk
await db.query("select 'hello' as message")

Under 3 MB gzipped, starts in milliseconds, persists to the filesystem or IndexedDB, and supports real extensions including pgvector. This stopped being a curiosity a while ago: it crossed 10 million weekly npm downloads this year, and Prisma, Firebase, and Netlify all ship it as the local engine behind their database products.

Where it wins: test suites (a fresh, real Postgres per test, no containers in CI), instant onboarding, browser playgrounds, coding-agent sandboxes, any environment where Docker isn't available.

Where it doesn't: it's single-connection and single-user. No replication, not a production database, and tools that expect a TCP connection string need an adapter. It's a library, and everything that implies cuts both ways.

2. Native install (~50 to 300 MB)

Homebrew, apt, or Postgres.app. The old way, and still the fastest raw Postgres you can run, since there's no VM and no container layer.

Where it wins: one long-lived database you use daily, maximum performance, lowest conceptual overhead.

Where it doesn't: one global version for the whole machine. Two projects on different Postgres majors means version-manager gymnastics. It pollutes the host, upgrades are a small ritual, and "install Postgres 16 locally" is the onboarding step that fails differently on every teammate's laptop.

3. Docker (~400 MB image, plus the runtime)

The default answer of the last decade. docker compose up, one isolated Postgres per project, any version you like, throw it away when you're done.

Where it wins: version isolation per project, parity with a containerized production setup, and the whole team runs the identical environment from one committed file.

Where it doesn't: the real cost isn't the image, it's the runtime. Docker Desktop idles at gigabytes of RAM on Mac and Windows, licensing applies at larger companies, CI needs service containers with health checks and port juggling, and there are environments (locked-down laptops, cloud IDEs, agent sandboxes) where it simply can't run. You're running a VM to get a process.

4. Cloud dev branches (0 MB local, network required)

Neon-style branching, or your platform's preview databases: every PR gets its own copy-on-write database in the cloud, nothing on your machine.

Where it wins: production-identical infrastructure, instant branches with real data shapes, zero local footprint, great for review apps.

Where it doesn't: no network, no database. Every query pays a round trip, tests share remote state unless you're disciplined about branching, and it's the only option on this list with a monthly bill. It complements a local option more than it replaces one.

The cheat sheet

Use case	Pick
Unit and integration tests	PGlite (fresh DB per test)
CI pipelines	PGlite, or Docker service containers if you need TCP
One daily-driver database	Native install
Multiple projects, multiple versions	Docker
Matching containerized prod	Docker
PR preview environments	Cloud branches
Demos, workshops, browser sandboxes	PGlite

Most teams end up with two: something heavy for prod parity, something feather-weight for the inner loop. That split is the point. The 200 iterations a day don't need the faithful production copy; the last check before deploy does.

The Supabase-shaped footnote

One case the table above doesn't cover: your app doesn't talk to bare Postgres. If you build on Supabase, your client calls the platform's REST, Auth, Storage, and Realtime APIs, so a lightweight Postgres alone doesn't give you a lightweight backend. The official local stack solves it with Docker, about a dozen containers of it.

That's the gap tinbase fills: an open-source (MIT) Supabase-compatible backend that runs the whole API surface on PGlite, in one process, npx tinbase start, up in about two seconds, with the official supabase-js SDK working unchanged. Same idea as row 1 of the table, extended to the entire platform. It's alpha and aimed at local dev and tests, not production, which is exactly the inner-loop slot in the two-tier split above.

Whatever your stack, weigh the setup against how you actually spend your day. The database you iterate against should cost you nothing to start, nothing to reset, and nothing to explain in the onboarding doc.

AI App Builders in 2026: RapidNative vs Bolt vs v0 vs Lovable, an Honest Comparison

Russel Dsouza — Fri, 18 Sep 2026 10:05:38 +0000

These four tools are not four answers to one question; they're answers to different questions
v0: best-in-class React UI, no backend story
Lovable: fastest full-stack web MVP, deep Supabase wiring, web only
Bolt: browser IDE, most framework-flexible (Expo included), deployment is on you
RapidNative: mobile-first; full React Native + Expo apps with the backend wired
Disclosure up front: I work on RapidNative. The competitors' wins below are real wins.

The "AI app builder" category has exploded, and most comparisons read like feature-matrix theater. Having used all four of these for real projects (and shipping one of them), here's the honest version: each tool optimizes for a different job, and picking by hype instead of by job is how you lose a weekend.

v0 (Vercel)

v0 turns prompts into React components with shadcn/ui and Tailwind, and it produces the cleanest, most conventional UI code in the category. If you live in the Next.js/Vercel world, the design fidelity and deployment integration are genuinely excellent.

The boundary is just as clean: it's a frontend tool. No backend generation; your API routes, database, and auth are your problem. That's not a flaw, it's the product's shape.

Pick v0 when: the job is beautiful React UI inside a stack you already own.

Lovable

Lovable is the most complete prompt-to-web-app tool: frontend, Supabase database, auth, even RLS policies, wired together from a description. It's also the most accessible of the four for people who don't write code, which explains its trajectory.

The boundary: it generates web code. React for browsers, not React Native for phones. A Lovable app in a mobile webview is still a website.

Pick Lovable when: the job is a full-stack web MVP, fastest, especially if you're non-technical.

Bolt (StackBlitz)

Bolt gives you an AI pair inside a browser IDE, and it's the most framework-flexible of the group: React, Next.js, Svelte, Astro, and yes, Expo. For a technical user who wants direct code control and iteration speed in a tab, it's the strongest fit.

The mobile boundary is subtler here, and it's where I should be precise since this is my lane: Bolt can generate Expo projects, but mobile is one framework among many rather than the product's center of gravity, and getting from generated code to a store build (EAS setup, certificates, submission) is manual work it doesn't do for you.

Pick Bolt when: you're technical, want an in-browser IDE, and value flexibility across stacks.

RapidNative

Full disclosure again: this is the one I work on, so weigh accordingly.

RapidNative exists for one job: native mobile apps. Prompts, screenshots, PRDs, or sketches in; complete React Native + Expo + TypeScript projects out, with navigation, theming, and the Supabase backend wired, built as apps headed for the App Store and Play Store rather than as websites that might one day get wrapped. You export and own the code.

The honest boundaries: it's not the tool for a web SaaS (use Lovable), not a general-purpose IDE (use Bolt), and if your job is pixel-perfect web UI, v0 will out-design it. Mobile-first cuts both ways.

Pick RapidNative when: the deliverable is an iOS/Android app, not a website.

The actual decision

The category's dirty secret is that the web/mobile split matters more than any feature comparison. Almost every tool in this space builds web apps; if you're shipping to a browser, you have great options and this article barely matters. If you're shipping to the app stores, the field narrows sharply, and "supports Expo" and "built for Expo" are different products.

These tools also compose. Plenty of teams run Lovable or Bolt for their web app and RapidNative for the mobile app, same Supabase underneath. Treating this as a winner-take-all bracket is the feature-matrix brain talking.

Pricing, for completeness: all four land in the same rough $20-25/month ballpark for pro tiers as of writing, with credit systems that vary. Don't pick on price; at these numbers, one saved afternoon pays the annual difference.

The one-line version

Web UI: v0. Full-stack web, fastest: Lovable. Browser IDE with maximum flexibility: Bolt. Native mobile apps, end to end: RapidNative.

What are you building, and which of these did you end up on? Genuinely curious how the split looks in the comments, especially from anyone who's shipped with two of them.

Postgres RLS in Local Dev: The Three Silent-Fail Modes That Ship to Prod

Russel Dsouza — Wed, 16 Sep 2026 05:28:31 +0000

RLS doesn't fail loudly. A table with no policies and RLS off returns every row, to everyone, and looks like a working app
Three ways local dev hides that: migrations that never run ENABLE ROW LEVEL SECURITY, a dev connection that bypasses RLS, and views that evaluate as their owner
All three pass every test you'd write in the happy path, because the happy path is "the data shows up"
A 30-line SQL check at boot catches every one of them, in about 50ms

Row Level Security has one property that makes it different from almost every other security control: when it's not working, the app works better. More rows come back. Nothing errors. Your local dev environment looks great right up until a customer in production sees another customer's invoices.

I've now seen this ship three different ways, and the fix for all three is the same boring boot-time check. Here's each failure and then the check.

Silent-fail 1: your migrations never enabled it

RLS is off by default on every table in Postgres. CREATE TABLE gives you a table with no row security, and it stays that way until something explicitly runs:

alter table invoices enable row level security;

The Supabase dashboard's table editor does this for you. Nothing else does. If you write migrations in raw SQL, dbmate, Prisma, Drizzle, Knex, or anything that turns a schema file into DDL, you get a table with RLS off, no warning, and no policies. And a table with RLS off and no policies is a table with no access control at all.

The Prisma case is the sneakiest, because Prisma's schema language has no concept of RLS. You write:

model Invoice {
  id      String @id @default(uuid())
  userId  String
  amount  Int
}

and prisma migrate dev generates a perfectly correct CREATE TABLE with no ENABLE ROW LEVEL SECURITY. You have to add it in a hand-written migration, and remember to do it for every table, forever.

There's a second half most people miss even after they've enabled it. The table owner bypasses RLS unless you also run:

alter table invoices force row level security;

Without force, the role that created the table (often the same role your migrations run as, often the same role your app connects as in dev) walks straight through every policy.

Silent-fail 2: your dev connection can't see RLS at all

Superusers bypass RLS. Roles with the BYPASSRLS attribute bypass RLS. Table owners bypass RLS unless force is set. In a lot of local setups, the app connects as one of those.

The common version: local Postgres, connection string is postgres://postgres:postgres@localhost, the postgres role is a superuser. Every query the app makes runs with RLS silently disabled. Your seed script inserted rows for five fake users, your UI shows all five users' data when logged in as one of them, and it looks like a demo, not a leak.

In production the app doesn't connect as a superuser. It connects as authenticated through PostgREST, or as a scoped application role, and now the policies apply. If they're wrong, or missing, that's the first time anyone finds out.

You can check what you're running as right now:

select rolname, rolsuper, rolbypassrls
from pg_roles
where rolname = current_user;

If either boolean is true, RLS is decorative in this session.

The fix isn't "don't use the postgres role locally," because you need it for migrations. The fix is to run the app as the same role it runs as in prod, and only the migration step as the owner. Supabase-style stacks do this for you because the API layer always connects as anon or authenticated. Anything that hands your app a raw connection string doesn't.

Silent-fail 3: views evaluate as their owner

This one bit me after I'd fixed the first two.

Before Postgres 15, a view runs its underlying queries with the view owner's privileges, not the caller's. That's security-definer semantics, and it means RLS on the base tables is evaluated as the owner. If the owner is postgres, or the table owner, or anything with BYPASSRLS, the view returns every row regardless of who's querying it.

-- invoices has RLS enabled, forced, with a correct policy.
-- this view still leaks every row, because it runs as its owner.
create view invoice_summary as
  select user_id, sum(amount) as total
  from invoices
  group by user_id;

Postgres 15 added a way out:

create view invoice_summary
  with (security_invoker = true) as
  select user_id, sum(amount) as total
  from invoices
  group by user_id;

With security_invoker, the view runs as whoever called it and the base-table policies apply normally. On Postgres 14 or earlier there is no equivalent; you have to either not expose the view through your API layer, or replicate the policy logic inside the view's WHERE clause and hope nobody edits one without the other.

The reason this ships to prod is that the view works identically in dev and prod, and in both places it returns all the rows. The difference is only that in dev, all the rows is what you expected to see.

The 30-line boot check

None of the three failures produce an error. So produce one yourself. This runs at app boot in development and in CI, against whatever Postgres you're using locally, and refuses to start if any of the three conditions are true:

do $$
declare
  bad text;
begin
  -- 1. every table in public must have RLS enabled AND forced
  select string_agg(c.relname, ', ') into bad
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where n.nspname = 'public'
    and c.relkind = 'r'
    and (not c.relrowsecurity or not c.relforcerowsecurity);
  if bad is not null then
    raise exception 'RLS not enabled+forced on: %', bad;
  end if;

  -- 2. the current role must not bypass RLS
  if exists (
    select 1 from pg_roles
    where rolname = current_user
      and (rolsuper or rolbypassrls)
  ) then
    raise exception 'connected as % which bypasses RLS', current_user;
  end if;

  -- 3. every view in public must be security_invoker (PG15+)
  select string_agg(c.relname, ', ') into bad
  from pg_class c
  join pg_namespace n on n.oid = c.relnamespace
  where n.nspname = 'public'
    and c.relkind = 'v'
    and coalesce(
      (select option_value = 'true'
       from pg_options_to_table(c.reloptions)
       where option_name = 'security_invoker'),
      false
    ) = false;
  if bad is not null then
    raise exception 'views without security_invoker: %', bad;
  end if;
end $$;

Three catalog queries, roughly 50ms on a schema with a few hundred objects. Run it right after migrations apply and before the app accepts a request. If you have tables that legitimately shouldn't have RLS (lookup tables, public config), exclude them by name in check 1; the point is that the exclusion is explicit and reviewable rather than the default.

Check 2 is the one people push back on, because it means the app can't connect as postgres locally. That's the point. If your local app connects as a role that ignores RLS, you have never once tested your policies.

Where this actually runs

The check only means something if local dev is real Postgres with RLS semantics. Mocks, SQLite adapters, and in-memory Postgres emulators either don't implement RLS or implement it loosely enough that the check passes on schemas that would fail in prod. I ended up running it against tinbase, which is a single-process Supabase-compatible backend on real Postgres 17: the API layer connects as anon/authenticated the way hosted Supabase does, so check 2 passes naturally, and the catalog queries behave exactly as they will in prod. Full Docker Supabase works too; it's just heavier for a check that takes 50ms.

Whichever you use, the requirement is the same: the Postgres your app boots against locally has to be the Postgres that enforces RLS, or the boot check is testing nothing.

The pattern

Three silent failures, one shape: RLS not applying looks like RLS working, only with more data. Nothing in the normal test loop distinguishes "policy correctly returned my rows" from "no policy, returned all rows, and mine were among them."

The boot check turns the silent failure into a loud one at the earliest possible moment, which is the only place it's cheap. If you've got a fourth mode, I'd like to hear it. My current suspicion is SECURITY DEFINER functions called from policies, but I haven't seen that one ship yet.

Your App Store reviewer is a user. Your listing is a product page.

Russel Dsouza — Wed, 02 Sep 2026 11:06:01 +0000

Most submission guides are engineering documents. They explain how to make the technical parts work.

Almost none treat submission as a UX problem, which it is. The reviewer is a user with a time budget. Your listing is a product page competing in a grid. The same first-impression rules that apply to onboarding apply here, and almost nobody applies them.

The reviewer is a user

A first-pass reviewer spends a short, bounded time in your app. Roughly what they encounter:

The launch screen. Is it branded, or is it a white rectangle?
A sign-in screen, if you have one. Do they even need to sign in?
The first functional screen. Does it work with the account you provided?
One or two feature interactions. Do these match what your description claims?

If any of that breaks, you're rejected. If it merely takes too long to work out — a demo account that doesn't support the sign-in method they tried first, for instance — you can also be rejected for missing information, which is the same outcome with more steps.

The dry run: hand your app and your demo account to someone who has never seen it, give them a minute, and watch. Don't help. Wherever they hesitate, the reviewer will hesitate too, except the reviewer has other apps to get to.

Review notes: write a route, not credentials

This is the highest-value item here and it costs ten minutes.

Most teams fill the App Review Notes field with the minimum:

Email: reviewer@yourapp.com
Password: TestPass123!

That gets the reviewer into the app and no further. They then explore on their own, in whatever order occurs to them, and whatever they don't find, they conclude isn't there.

Better:

Email: reviewer@yourapp.com
Password: TestPass123!

Once signed in:
1. Tap + on the home screen to create a Budget.
2. Add two or three expenses.
3. Tap Reports in the tab bar for the visualisation.
4. Tap Share, top right, for the export flow.

All features are unlocked on this account. No paywall.

Same amount of reviewer time, far more of your app actually seen. It also pre-empts the most common completeness rejection, which is a reviewer concluding a feature doesn't exist because they didn't reach it.

The last line matters more than it looks. A reviewer hitting an unexpected paywall has to decide whether that's the intended experience, and that decision doesn't go your way.

Screenshots that survive being small

Search results render your screenshots at thumbnail size. That's where the install decision gets made, and text sized for a full-screen preview is unreadable there.

A hierarchy that works:

Screenshot 1. One enormous headline stating the single most valuable outcome. Nothing else. It must be readable at thumbnail size, which means far larger type than feels reasonable in the design file.

Screenshots 2 and 3. One feature each, device UI, short caption.

Screenshots 4 onward. Supporting features and social proof, for the minority who swipe.

The test costs nothing: scale your first screenshot down to roughly the width of a thumbnail and look at it. If you can't read the headline, neither can anyone else, and that's the only one most people ever see.

Changelogs people actually read

"Bug fixes and improvements" tells a user nothing, which means it gives them no reason to update, which means they stay on an older build and eventually conclude the app is abandoned.

One line per user-visible change:

• Faster launch on iOS 18
• Fixed: widget showing stale data after a sync
• Fixed: dark mode contrast on Settings
• Added: CSV export for Reports

Note what that does beyond informing. "Fixed: widget showing stale data" tells someone who hit that bug that you saw it. That's worth more than the fix, because a user who reported something and never heard back assumes nobody is home.

The connecting idea

Every item here is the same move: treating someone you can't talk to as a user with limited time and no context.

The reviewer can't ask you where the feature is. The person scrolling search results can't zoom in. The user on an old build can't tell whether the update is worth the download. In each case they make a decision with whatever you gave them, and in each case most teams gave them very little.

Automating the mechanical parts — generating changelog stubs from the release diff, checking listing assets before submission, keeping the workflow in one place — is what letsdeploy.it does. The judgement parts stay yours, and the review notes especially are worth writing by hand.

What's in your App Review Notes field right now? My guess is an email and a password, and that ten minutes spent there has a better return than anything else on this list.

Self-Hosted Supabase Doesn't Break Because Postgres Is Hard

Russel Dsouza — Fri, 28 Aug 2026 12:21:49 +0000

I spoke to teams who had run self-hosted Supabase in production. Some still do. Some moved back to hosted. A couple ended up assembling their own stack from primitives.

The question I wanted answered: is the pain "Postgres is hard", or something more specific?

Disclosure before anything else: I work on a Supabase-compatible runtime, so I had a stake in one of the possible answers. The findings below happen to point at a product shape close to what my team builds, and you should weigh them accordingly. I've tried to report what people said rather than what would be convenient.

Nobody complained about Postgres. Every team described it as boring and working.
The pain is the surrounding services: auth, realtime, storage, proxy, meta, and the rest
Version drift between local and production was named unprompted by every team
Realtime dropping events during deploy restarts was the second most common
Both are distribution problems, not database problems

The three failure modes

Ranked by how many teams raised each without prompting:

Auth service version drift between local and production. Every team.
Realtime falling over during deploy churn. Most of them.
Storage service behaving differently from S3 behind a reverse proxy. Several.

Postgres was described as boring and working, by everyone. Not one complaint.

The pain lives in the distribution: the wrapping services that turn a database into a platform. Auth, realtime, storage, functions, image proxy, gateway, metadata. Roughly ten moving parts, each with its own version, its own restart behaviour, and its own proxy quirks.

Version drift, in detail

This came up in every conversation.

The shape: you develop locally against current service versions. Production runs older ones, because upgrading is a maintenance window and there is always a reason to defer it. Then code that works locally fails in production, because something changed between those versions.

Error taxonomies are the usual culprit. An auth error name that exists in the version on your laptop does not exist in the version on your server, so the client falls through to a generic unknown-error path and tells you nothing useful.

One team described losing a full day to exactly this. The conclusion they reached, which several others reached independently: nothing about that day was Postgres.

The workaround everyone lands on is pinning local development to the same service versions as production. Which means every developer runs deliberately outdated services, nobody benefits from upstream fixes, and onboarding a new engineer means reproducing a bespoke pinned setup that exists in one person's head.

That is a distribution problem. Not a code problem, and not a database one.

Realtime during deploys

The second most common, and the more insidious of the two, because it produces no errors.

Rolling deploy. The realtime service restarts. WebSocket clients disconnect, then reconnect, which works correctly. But during that reconnect window, subscriptions can miss changes.

Nobody sees an error. Users just don't get updates. The team finds out days later, when a customer mentions that a change on one device never showed up on another.

The workaround: deploy realtime only in low-traffic windows and manually verify subscription counts either side. That is toil, and it scales with team size in the wrong direction.

Storage behind a proxy

Less universal, sharper when it lands. Several teams lost an afternoon to 403s on presigned uploads that worked locally and failed behind nginx or HAProxy.

The cause was some combination of header case sensitivity and a Host header mismatch. Straightforward once you know where to look, and genuinely baffling if you assumed "S3-compatible" means "behaves identically to S3 in every deployment topology."

It doesn't. Compatibility claims describe an API surface, not a network path.

What this actually implies

The useful finding isn't that self-hosting is hard. It's that the difficulty is misattributed.

Self-hosted Supabase doesn't fail because a database is hard to run. It fails because a platform assembled from around ten independently versioned services has a coordination problem, and coordination problems don't announce themselves. They present as a weird error in production, an event that didn't arrive, a 403 that only happens behind the proxy.

Two things would remove most of what these teams described:

Ship every service at one version, by construction. Not tooling that makes alignment easier. A shape where misalignment isn't expressible, because the whole platform is one artifact with one version.

Make realtime restarts transparent. Resumption plus event replay across the disconnect window, so a deploy stops being a silent data-loss event.

Proxy compatibility is a third, and it becomes essential rather than nice-to-have the moment anyone puts this behind enterprise networking.

I'll be straightforward about the conflict here: the first of those describes tinbase, which is what I work on. It is a single binary, so services can't drift apart. It does not solve the second, and I'm not aware of anything that does yet.

It's also a local development runtime rather than a production self-hosting replacement, which is worth stating plainly given that everything above is about production.

If you're running it now

If you're hitting these, you aren't doing anything wrong. The shape of the distribution is doing it, and every workaround people described was a reasonable response to an unreasonable coordination problem.

Pin your versions deliberately rather than accidentally. Write down which ones, somewhere a new engineer will find. Deploy realtime when it costs least. And treat "S3-compatible" as a claim about an API, not a promise about your network.

If you run self-hosted Supabase in production, what broke that wasn't the database? I'm collecting these, and my expectation is that almost none of the answers are Postgres.

Should You Self-Host Supabase? It's Three Decisions, Not One

Russel Dsouza — Thu, 27 Aug 2026 10:53:45 +0000

The self-hosting argument never resolves because both sides are right about different things.

Own your data, no lock-in, cheaper at scale. Also true: it's an operational tax, upgrades cascade, and local drifts from prod.

Both hold. "Should I self-host Supabase" isn't one question, it's three, and most people answer all three with a single decision.

Local dev, staging, and production are separate decisions with separate constraints
Picking one answer for all three is where the pain comes from
Local: worst default, cheapest to change
Production: usually-correct default, most expensive to change
Most people optimise the expensive one and inherit the cheap one

The three decisions

Decision	Optimises for	Cost of getting it wrong
Local dev	Iteration speed, low friction	Paid daily, compounds quietly
Staging	Fidelity to production	Bugs reach users
Production	Reliability, operational burden	Paid at the worst possible moment

They pull in opposite directions. Local wants to be fast and disposable. Staging wants to be identical to prod. Production wants to be reliable and ideally someone else's problem.

No single answer satisfies all three, which is why whichever one you pick feels wrong somewhere.

Local: the one worth changing

Worst default, and almost nobody revisits it.

The standard setup runs the full container stack. Gigabytes of RAM, tens of seconds to boot, a laptop that gets loud. The consequence isn't complaints, it's that people stop running it.

That's the actual cost and it appears in no comparison table. A local environment nobody runs is one that quietly stops working, and you find out the day prod breaks and three people spend an afternoon building a repro from scratch.

Switching cost here is also the lowest of the three. Local is disposable. If a lighter setup doesn't work, you lost an afternoon.

How to tell: is anyone on your team pointing at staging instead of running locally? Then you already have your answer.

Single-binary runtimes exist for this now. tinbase is the one my team builds, so discount accordingly. It serves the Supabase-compatible surface from one process. It's a local dev runtime, not a production self-hosting replacement, which is exactly why these decisions need separating.

Staging: the one people skip

Staging is where the parity argument belongs, and it's usually where nobody's looking.

If local runs a different implementation from prod, local passing stops guaranteeing prod passing. Real cost. But the fix isn't making local heavier, it's having something between local and prod that's genuinely faithful.

Run the full stack in staging. Once before a release, not every morning. One boot a week instead of one a day, and fidelity lands where fidelity matters.

Skip staging and try to get parity out of local, and you end up with the worst combination available: a heavy local setup that still isn't identical to prod.

Production: highest stakes, usually-correct default

Self-hosting prod means owning image updates, CVE patching, cert renewal, backup verification, and restore drills.

With a platform team, that amortises across roles that already exist. Without one, it's evenings and weekends, and it has no deadline pressure right up until it has all of it.

The honest test isn't cost. It's: when did you last restore from a backup?

If never, you're not self-hosting. You're holding an unverified assumption about data you can't afford to lose. A backup nobody has restored is a hypothesis.

Self-hosting prod is reasonable when: someone owns operations, upgrades have a runbook, restore drills are scheduled, and the hosted bill justifies the work. All four. Not one.

The mistake

People spend their thinking on the production decision, where the default is usually right and switching is expensive. Then they inherit the local decision, where the default is usually wrong and switching costs an afternoon.

Flip the allocation. Change local this week. Leave prod alone until all four conditions above are true.

Optimise the decision you pay for daily, not the one you argue about online.

Worked examples

Solo dev with a live product:

Layer	Choice	Why
Local	Lightweight, no containers	Runs constantly, friction compounds
Staging	Full stack, before releases	Parity where it counts, weekly not daily
Production	Hosted	No ops capacity, no restore drills happening

Team of fifteen with a platform engineer:

Layer	Choice	Why
Local	Developer preference	Individual cost, individual call
Staging	Full stack, always running	Fidelity is cheap when someone owns it
Production	Either, run the numbers	Ops capacity makes it a real option

Notice what moves. Production changes with team structure. Staging barely moves. Local is personal and should be.

The short version

If you have no staging environment, local is doing two jobs and doing at least one badly. Fix that first.

Then: light local, faithful staging, boring production. Revisit production only when all four conditions hold.

Which of the three did you actually decide on purpose? My bet is production, because it feels consequential, and that local came from a quickstart guide three years ago and nobody has touched it since.

Migrating a Supabase Local Dev Project to Tinbase in 10 Minutes

Russel Dsouza — Mon, 24 Aug 2026 12:26:47 +0000

If you run Docker-based Supabase for local development and want to try the same stack on a single binary, this is the walkthrough. It takes about ten minutes for a typical project and nothing about it is destructive.

Tinbase is a Supabase-compatible runtime that ships as one executable. Your app code doesn't change, the SDK is the same, only the connection string and the way you boot the backend differ.

Install the binary, dump your schema, import it, swap the connection string
Your Docker Supabase state is never touched, so rollback is a git checkout away
Auth and realtime work through the same @supabase/supabase-js client
Edge functions and non-standard extensions are where the gaps are

Prerequisites

macOS, Linux, or Windows
A working Docker-based Supabase local environment you can currently run
A Node project using @supabase/supabase-js

This assumes your app connects through the standard SDK. Direct low-level Postgres connections work too, but aren't covered here.

Step 1: install the binary

curl -fsSL https://tinbase.dev/install.sh | sh

If you'd rather not pipe a script into a shell, download and read it first. Same URL, no pipe.

Verify the install:

tinbase --version

Step 2: dump your Supabase schema

With Docker Supabase running:

supabase db dump --file schema.sql --schema public

That produces a schema.sql containing your tables, functions, RLS policies, and triggers.

The auth schema doesn't need exporting. Both platforms manage it themselves, and importing one over the other creates conflicts rather than continuity.

Step 3: import into Tinbase

Start in a fresh directory:

mkdir tinbase-dev && cd tinbase-dev
tinbase up

In a second terminal, import:

tinbase psql -f ../schema.sql

Confirm the tables landed:

tinbase psql -c '\dt public.*'

If this errors, read the message rather than re-running. Import failures are almost always a missing extension, and the error names it.

Step 4: point your app at it

Docker Supabase serves on 54321. Tinbase uses a different default port, configurable through an environment variable.

- SUPABASE_URL=http://localhost:54321
- SUPABASE_ANON_KEY=eyJhbGciOiJI...
+ SUPABASE_URL=http://localhost:8080
+ SUPABASE_ANON_KEY=<from `tinbase config show`>

Run tinbase config show to get the anon key for your local instance. It's different from your Docker Supabase key, which is the step people miss and then spend twenty minutes debugging a 401.

Step 5: verify

Three checks, in this order:

Sign up a test user through your app's normal signup flow, then confirm the row exists:

tinbase psql -c 'SELECT id, email FROM auth.users'

Sign in as that user and confirm a protected route resolves. This exercises JWT issuing and verification, which is the part most likely to differ.
Trigger a realtime change if your app subscribes to anything, and confirm the subscription fires.

If all three pass, you're done. If step two fails, it's the anon key from step four.

Rolling back

Your Docker Supabase state was never modified.

git checkout .env
supabase start

That's the entire rollback. Worth knowing before you start, because it changes how much you need to think about this.

What doesn't migrate cleanly

Known gaps, worth checking against your project before you begin:

Edge functions written for Deno. Tinbase runs a v8 isolate rather than Deno, so Deno-specific APIs need adjusting.
Uncommon Postgres extensions. The widely used ones are preloaded; anything niche may not be.
Storage. Tinbase uses the local filesystem rather than S3-compatible object storage, which is usually what you want locally but differs from production.

For a standard project using Postgres, auth, realtime, and the JS client, none of these apply.

That third one is worth a thought regardless of which tool you use. If your local storage layer behaves differently from production storage, you have a category of bug that only appears after deploy, and no local setup will surface it.

Why bother

The honest version: if Docker Supabase boots fast enough on your machine and you never avoid running it, there's no problem to solve here.

The case for a single binary is about the days you'd otherwise skip local entirely. Boot time and memory footprint determine whether a local environment gets used, and an environment nobody runs is one that quietly stops working.

Full docs and source are at tinbase.dev. MIT licensed.

If you try this, I'm interested in what broke. Particularly edge functions, since that's the gap where "small syntax adjustments" covers a wide range of actual experiences.

Your App Store Submission Should Be a Git Tag, Not a Ritual

Russel Dsouza — Mon, 17 Aug 2026 10:37:00 +0000

Every team I've seen ship a React Native app has the same undocumented ceremony. Someone opens Xcode. Someone bumps a version number by hand. Someone drags screenshots into App Store Connect. Someone remembers, halfway through, that the Android build needs a different keystore.

It takes a day, it happens every release, and roughly none of it is a decision. It's clicking.

Here's the version where you push a tag and go do something else.

eas build and eas submit cover the binary path end to end, no local Xcode
Store metadata belongs in a JSON file in your repo, not in a web form
Build numbers should auto-increment in CI, never by hand
Google Play's track model is the part that changes your schedule, not just your tooling
Screenshots and review replies stay manual, and should

The parts that are actually mechanical

Sort the release into two piles: things requiring judgement, and things requiring clicking.

Judgement: what the screenshots say, what the release notes claim, whether the feature is ready, how to respond to a rejection.

Clicking: compiling, signing, uploading, incrementing versions, pushing descriptions and keywords, promoting between tracks.

The second pile is most of the day and none of the value.

Build and submit without touching Xcode

Two commands, once eas.json is configured:

eas build --platform all --profile production
eas submit --platform all --latest

The config that makes submit work:

{
  "cli": { "version": ">= 5.0.0" },
  "build": {
    "production": {
      "autoIncrement": true,
      "env": { "APP_ENV": "production" }
    }
  },
  "submit": {
    "production": {
      "ios": {
        "appleId": "you@example.com",
        "ascAppId": "1234567890",
        "appleTeamId": "ABCD123456"
      },
      "android": {
        "serviceAccountKeyPath": "./secrets/play-service-account.json",
        "track": "internal"
      }
    }
  }
}

Two things in there matter more than they look.

autoIncrement kills an entire category of failed uploads. Manually managed build numbers get duplicated roughly every time two people cut a release in the same week, and the error you get back from App Store Connect is not helpful about why.

track is the Google Play release channel, and it's the thing worth understanding properly.

The Google Play track model

Play has four tracks: internal, alpha (closed testing), beta (open testing), and production. Builds get promoted between them.

This is normally described as a testing convenience. For a new developer account it's a scheduling constraint, because personal accounts created after November 2023 have to run closed testing with at least 12 testers opted in for 14 continuous days before production access is even available.

Which means your CI config has a scheduling consequence:

"android": {
  "serviceAccountKeyPath": "./secrets/play-service-account.json",
  "track": "alpha",
  "releaseStatus": "completed"
}

Point the pipeline at alpha on day one, with whatever build you have. The fourteen days run while you keep working. If you wait until the app is finished to think about tracks, you've added two weeks to the end of your timeline instead of overlapping them with the middle.

Automating the upload is the easy part. Automating it early is the part that actually saves time.

Metadata as a file, not a form

App descriptions, keywords, categories, and release notes are content. Content belongs in version control.

{
  "configVersion": 0,
  "apple": {
    "info": {
      "en-US": {
        "title": "Your App",
        "subtitle": "Short value proposition",
        "description": "Full description text.",
        "keywords": ["keyword", "another"],
        "releaseNotes": "What changed in this build."
      }
    }
  }
}

eas metadata:push

The benefit isn't saved keystrokes. It's that your store listing goes through code review like everything else, and you can see in git log when the description changed and who changed it. Ask anyone who has tried to work out why their keywords are different from last month.

Wiring it to a tag

name: release
on:
  push:
    tags: ['v*']

jobs:
  ship:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: expo/expo-github-action@v8
        with:
          eas-version: latest
          token: ${{ secrets.EXPO_TOKEN }}
      - run: npm ci
      - run: eas build --platform all --profile production --non-interactive
      - run: eas submit --platform all --latest --non-interactive
      - run: eas metadata:push

--non-interactive matters. Without it the CLI will sit waiting for a prompt nobody is there to answer, and your job times out twenty minutes later with no useful output.

Credentials go in CI secrets. The Play service account JSON should be a base64-encoded secret written to disk at runtime, never a file in the repo. Same for the Apple API key.

What should stay manual

Screenshots. Generating them is automatable and mostly a bad idea. Store screenshots are a message hierarchy, not a screen dump, and the automated ones look exactly like what they are.

Release notes. "Bug fixes and performance improvements" is what happens when you automate this. Write them.

Rejection responses. A rejection is a conversation. Attaching a demo video and explaining your native functionality resolves a surprising share of them, and none of that is scriptable.

The decision to ship. Obvious, but worth stating, because a pipeline this smooth makes it easy to release without anyone actually deciding to.

The part that compounds

The first release you automate takes longer than doing it by hand. The fifth one takes four minutes.

More usefully, it changes what a release costs psychologically. When shipping is a day of clicking, you batch changes, which makes each release bigger, which makes each release riskier. When it's a tag, you ship the one-line fix on Tuesday instead of holding it for the next big push.

Teams doing this across several apps eventually want the pipeline itself to be a product rather than a .github folder copied between repos. letsdeploy.it does that part, carrying builds, metadata, and store assets through submission so each release stops consuming a day.

But the tooling matters less than the reclassification. Look at your last release and mark each step as judgement or clicking. The clicking pile is bigger than you think, and all of it is someone's afternoon.

What's still manual in your release that shouldn't be? I'll bet at least one person reading this is still incrementing build numbers by hand.

Mobile App Analytics in React Native: What to Track (and What to Skip)

Russel Dsouza — Thu, 13 Aug 2026 05:01:19 +0000

I have shipped enough React Native apps to see the same pattern every time: on launch day someone wires up fifty analytics events and six months later nobody on the team can explain what any of them are for. This is a working developer's guide to instrumenting a React Native or Expo app so the numbers actually mean something.

The Four Buckets

Every useful mobile app metric fits into one of four categories:

Acquisition: installs, CPI, CAC, install source, store conversion.
Activation: activation rate, time to value, onboarding funnel completion.
Engagement and Retention: DAU, MAU, stickiness (DAU/MAU), session length, D1/D7/D30 retention cohorts, churn.
Monetization: ARPU, conversion rate, LTV, trial-to-paid, renewal rate.

Track a couple from each bucket. Skip the rest until you outgrow them.

Technical Metrics That Are Actually Product Metrics

Performance is not a "nice to have." A slow, crashy app poisons every other metric.

Crash-Free Session Rate: target 99.5%+ for consumer, 99.9%+ if you take payment.
ANR Rate (Android only): Play Store visibility suffers when this crosses Google's bad-behavior threshold.
Cold Start Time: under 500ms good, over 1500ms bad. Hermes bytecode substantially cuts JS parse time vs JSC.
API p95 Latency: measured from the client, not the server. The tail is where users feel pain.

The Stack I Actually Use in 2026

Concern	Tool
Product analytics	PostHog (self-hosted) or Amplitude (free tier)
Errors / performance	Sentry
Subscriptions	RevenueCat
Attribution	SKAdNetwork + Play Install Referrer (free, built-in)

All of these have first-class Expo config plugins in 2026. npx expo install @sentry/react-native posthog-react-native react-native-purchases gets you 80% of the way there.

The One Instrumentation Pattern That Scales

Wrap your SDK. Always. Every screen and component should import track() from a single module, never the SDK directly.

// src/analytics/track.ts
import PostHog from 'posthog-react-native';

type EventName =
  | 'signup_completed'
  | 'paywall_viewed'
  | 'subscription_started'
  | 'workout_logged';

type EventProps = Record<string, string | number | boolean>;

export function track(event: EventName, props: EventProps = {}) {
  PostHog.capture(event, props);
}

export function identify(userId: string, props: EventProps = {}) {
  PostHog.identify(userId, props);
}

Rules I have learned the hard way:

Event names are verbs, past tense. paywall_viewed, not paywall.
User properties are stable, few, semantic. plan, cohort_week, platform_version. That is enough for 90% of segmentation.
No PII in event names or properties. Not even hashed. Just don't.
Type the event names. If your event schema is a type, refactoring becomes safe. Untyped strings are how event soup starts.

Metrics I Have Deleted From Every Dashboard

Total installs, unless you are showing it next to activated installs.
Screen views as a KPI. Useful for debugging nav, useless as a headline.
"Engagement" as a single number. It's a portfolio, not a scalar.
App Store rating without volume and recency alongside it.

Rule: for every metric, name the decision it drives, the owner of that decision, and the cadence they act on it. Can't do all three? Delete.

Privacy: The 2026 Baseline

PrivacyInfo.xcprivacy is mandatory if any of your SDKs touch required-reason APIs. Most analytics SDKs do. Skip this and your App Store submission gets rejected.
Consent for EU: non-negotiable for behavioral events. Use Klaro if you want an OSS option.
First-party > third-party: server-side event streams from your app to your own backend are increasingly the safe default. PostHog and Amplitude both support this.

Where to Go From Here

If you're starting from scratch, spin up an app with an AI React Native builder like RapidNative. It scaffolds Expo apps with the wrapper pattern above, and event schemas become just another thing you can prompt for. Faster than doing the boilerplate by hand, and consistent across every screen.

If you already have an app, delete half your events tomorrow. You'll be fine.

Which metric have you deleted from a dashboard and never missed? That list is more useful than any tracking plan; drop yours in the comments.

Best React Native Starter Templates in 2026 (Compared)

Russel Dsouza — Thu, 06 Aug 2026 11:55:59 +0000

Best React Native Starter Templates in 2026 (Compared)

One of the first questions every React Native developer asks is:

"What's the best React Native starter template?"

It's a fair question.

Nobody wants to spend the first week of a project configuring navigation, authentication, theming, folder structure, and dozens of reusable screens before building their actual product.

A good starter template should help you ship faster—not introduce more decisions.

After trying several popular React Native starter kits and boilerplates, here are the things that actually matter.

What makes a good React Native starter template?

Most comparison articles focus on the tech stack.

Expo vs React Native CLI
TypeScript
State management
Navigation
Authentication

Those are important, but they're only part of the picture.

A great starter template should also include:

Production-ready screen layouts
Dark mode support
Consistent design system
Reusable components
Clean project structure
Easy customization
Good documentation

The goal isn't just to start a project.

It's to reduce the amount of UI you have to rebuild.

What developers usually search for

Most developers aren't actually searching for a "starter template."

They're trying to solve a specific problem.

Common searches include:

React Native login screen
React Native onboarding template
React Native dashboard UI
React Native settings screen
React Native profile screen
React Native e-commerce UI
React Native chat UI
React Native admin dashboard

If your starter template doesn't include these, you'll probably end up building them yourself.

Popular React Native starter templates

Expo Router Starter

Perfect if you want the official Expo experience.

Pros

Officially maintained
Great developer experience
Excellent documentation

Cons

Minimal UI
You'll build most application screens yourself

Ignite

Ignite has been around for years and provides a solid architecture.

Pros

Opinionated structure
State management included
Great documentation

Cons

Focuses more on architecture than reusable UI.

React Native Boilerplates

There are dozens of community boilerplates.

Some are excellent.

Some haven't been updated in years.

Before choosing one, always check:

Last commit
Issue activity
Documentation quality
React Native version
Expo compatibility

gluestack-ui Pro

Unlike traditional starter templates, gluestack-ui Pro focuses on the part most templates leave out—production-ready app screens.

Instead of only giving you components, it includes reusable screens for common app flows such as:

Authentication
Onboarding
Dashboard
Settings
Profile
Commerce
Chat
Wallet
Media
Social

They're built with:

Expo 54
TypeScript
NativeWind v5
gluestack-ui v5
Design tokens
Light & Dark mode

Learn more

Questions to ask before choosing a starter template

Before adopting any template, ask yourself:

✅ Can I customize it easily?

✅ Does it support theming?

✅ Is the code easy to understand?

✅ Will it still work after upgrading React Native?

✅ Does it include the screens I'll end up building anyway?

These questions matter more than the number of GitHub stars.

Final thoughts

The best React Native starter template isn't necessarily the one with the biggest feature list.

It's the one that removes the most repetitive work.

Whether that's a lightweight boilerplate, a full architecture starter, or a reusable screen library depends on your workflow.

If your team repeatedly builds the same authentication flows, dashboards, settings pages, and onboarding experiences, starting with production-ready screens can save days of development on every project.

What starter template are you using today, and what's the first thing you always end up changing?

Gluestack-ui Pro: 55+ Production-Ready React Native Screens

Russel Dsouza — Wed, 05 Aug 2026 07:30:45 +0000

Hey everyone!

If you've ever built a React Native application, you've probably faced this problem. You start a new project, you're excited to build features, solve real user problems, and ship something amazing.

But before you get there, every application needs the same set of screens.

Authentication
Profile
Settings
Chat
Dashboards

Almost every project starts with these. The problem isn't that they're difficult to build. The problem is building them well.

Because this is where users get their first impression of your product. If these screens don't feel polished, the whole application doesn't feel premium. So developers spend hours perfecting layouts, spacing, typography, animations, responsiveness, and design consistency.

And that's where a lot of development time disappears. Not into building unique features, but into rebuilding the same UI foundation over and over again.

Introducing gluestack-ui Pro

That's exactly why we built gluestack-ui Pro.

Instead of starting every project from scratch, you get a collection of premium, production-ready React Native screens that are ready to integrate into your application. Simply customize them according to your brand, connect your own APIs and business logic, and focus on building the features that make your product unique.

55+ Ready-to-use Screens

Right now, it comes with 55+ of the most commonly used React Native screens.

Whether you're building a startup, an MVP, or a client project, you'll find most of the common screens already available.

The layouts are clean. The spacing is consistent. The typography feels polished.

We've also added smooth animations throughout the application, making the entire experience feel modern and premium. And these aren't just UI mockups. These are real React Native screens that you can integrate directly into your application and customize however you like.

The Codebase & Architecture

The codebase is clean and well-structured. The project is easy to navigate, making customization straightforward even for larger applications.

Design tokens are a big part of that. Instead of hardcoded values scattered throughout the project, everything is driven by tokens.

So if your designer decides to change the brand color later, you don't have to hunt through dozens of files updating components one by one. Just update the token once, and the changes are reflected across the entire application. The entire styling system is built using Tailwind, which keeps the code clean, readable, and easy to maintain.

Modern Tech Stack

gluestack-ui Pro is built with the latest React Native technologies:

Layer	Version
Expo	54
NativeWind	v5
Gluestack UI	v5
Language	TypeScript

Seamless Customization

Changing the primary color updates it across the entire application. Same for the background color. One small change updates every screen that uses those design tokens.

That's the advantage of a proper tokenized design system. You update your design in one place, and the entire application stays consistent.

There are also several beautifully designed themes included out of the box, and every theme works seamlessly with both Light Mode and Dark Mode.

Wrapping Up

One important thing before we wrap up. gluestack-ui Pro isn't trying to replace development. You still own your backend. Your APIs. Your authentication. Your business logic.

gluestack-ui Pro simply removes the repetitive UI work, giving you a strong foundation so you can focus on building your actual product.

If you're looking to build React Native applications faster, without spending weeks rebuilding the same UI over and over again, you know where to start. gluestack-ui Pro gives you a production-ready foundation that you can integrate, customize, and make your own.

Spend less time building common screens, and more time building the features that make your product unique.

We're launching on Product Hunt today. If any of this is useful to you, a look means a lot.

What's the screen you rebuild most often? Curious whether it matches ours.

How tinbase Reimplements Supabase's Wire Protocols in a Single Process (and Runs in a Browser Tab)

Russel Dsouza — Thu, 30 Jul 2026 07:47:14 +0000

tinbase is live on Product Hunt today — an open-source, Supabase-compatible backend that runs without Docker. Support the launch here: [https://www.producthunt.com/products/tinbase]

The problem

Local Supabase development means Docker: a 12-container stack and over 2 GB of images to get Postgres, PostgREST, GoTrue, Storage, and Realtime running on a laptop. The platform itself is excellent; the local loop is heavy. And in some environments it isn't just heavy — it's impossible. tinbase was originally built for lifo, a project that maps Linux APIs into the browser, to let Expo apps run fully in-browser with full-stack capability — database, auth, storage, realtime, no server. It's part of the RapidNative ecosystem, and Docker was never an option in that environment.

That raised the question: what if the entire Supabase API surface were just a process? One process, embeddable anywhere Node — or a browser tab — runs?

Why Supabase compatibility instead of yet another backend

tinbase deliberately avoids inventing another proprietary BaaS API. Supabase's real strength is that it functions as an open standard: PostgREST's REST conventions, GoTrue's auth flows, and a documented realtime protocol, all served by the most widely adopted SDK in the space. Implement those protocols faithfully, and every existing supabase-js app, tutorial, and starter template works with zero changes — and every project stays portable back to hosted Supabase.

That portability is the design constraint everything else follows from. tinbase reads the same supabase/migrations/*.sql files and follows the Supabase CLI's migration conventions, tracking them in supabase_migrations.schema_migrations. It's a different runtime, not a different platform.

The architecture

tinbase is a single TypeScript process with three layers.

1. Protocol layer. Every service is a pure (Request) => Response fetch handler: the PostgREST query grammar (filters, embeds — to-one, to-many, many-to-many via junction, !inner — JSON paths, upsert, RPC), GoTrue's auth endpoints (email/password, anonymous sign-in, OAuth with PKCE, session refresh with rotation), storage APIs with signed URLs, and realtime speaking the Phoenix protocol over a hand-rolled ~150-line RFC 6455 WebSocket server. Because these are plain fetch handlers rather than a bound HTTP server, they run behind node:http (or Bun.serve) on a machine — or get handed to supabase-js as a custom fetch and invoked directly in-process, with no server at all. That one decision is what makes browser mode possible.

2. Engine adapter layer. A thin interface over "a thing that runs Postgres SQL," with three implementations and honest tradeoffs:

Embedded native Postgres 17 — the default on macOS/Linux. First run downloads ~12 MB of platform binaries, then initdb with memory-lean settings: ~59 MB of RAM at boot, listening only on a private unix socket. Real RLS, triggers, foreign keys, jsonb.
PGlite (wasm) — ElectricSQL's Postgres compiled to WASM. Zero setup, runs anywhere Node runs and in the browser, and it's the default on Windows. The tradeoff is memory: its WASM heap sits around 575–650 MB.
pg-mem — a pure-JS in-memory subset at a 3.6 MB install, the lightest option for browser previews. No RLS or cron, but the REST CRUD surface, auth, edge functions, and realtime all work, with change events synthesized in JS by the REST layer.

3. Studio. A Supabase-Studio-style dashboard at /_/ — table editor with row CRUD, SQL editor, user management, storage, RLS policies — compiled to a single self-contained HTML file so it works even inside the single binary.

The hard parts

RLS across engines. Every REST and storage request runs inside a transaction with SET LOCAL role and request.jwt.claims, so a policy like using (user_id = auth.uid()) behaves identically to hosted Supabase — whether the SQL executes in native Postgres 17 or in WASM.

HTTP without HTTP. In a browser tab there is no listener socket. supabase-js expects a URL, so tinbase hands it a custom fetch that routes requests straight into the protocol handlers in-process:

const supabase = createClient('http://localhost', backend.anonKey, {
  global: { fetch: (input, init) => backend.fetch(new Request(input, init)) },
})

Realtime without WAL. Hosted Supabase reads the write-ahead log; tinbase feeds postgres_changes from triggers plus pg_notify, and even applies per-subscriber RLS filtering on INSERT/UPDATE events by re-checking the row as that user. (DELETE events can't be re-queried — the row is gone — which is documented as a known gap.)

Proving compatibility. Claiming "supabase-js works unchanged" is easy; keeping it true is a test-suite problem. 120 tests run the real @supabase/supabase-js against the backend — REST via in-process fetch, realtime over actual WebSockets, zero mocks — and pass on both the wasm and native engines. Overall coverage lands around 80% of the supabase-js SDK surface, and roughly 90% of what a typical CRUD + auth + storage + realtime app actually calls.

The numbers

The footprint benchmark (reproducible via bench/footprint.ts in the repo) against the same workload — boot, 1,000 inserts, 1,000 filtered reads:

	tinbase (single binary)	Supabase local	PocketBase
Memory at boot	49 MB	1,441 MB	15 MB
Memory after workload	66 MB	1,626 MB	24 MB
Install size	92 MB	2,291 MB	30 MB
Processes	2	12 containers + Docker	1
Database	real Postgres 17 + RLS	Postgres 17	SQLite

The honest read: versus Supabase local, ~16–24x less memory and a ~2s boot instead of a minute, with the same SDK and APIs. Versus PocketBase, roughly 2.7x the RAM — but running real Postgres with RLS behind Supabase's exact wire APIs, so code and migrations move to hosted Supabase unchanged.

What it looks like in practice

npx tinbase start

#   API URL: http://127.0.0.1:54321
#   anon key: eyJ...

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

const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)
// everything below this line is unchanged app code
await supabase.auth.signUp({ email: 'me@example.com', password: 'secret123' })
const { data } = await supabase.from('todos').select('*, author:users(name)').eq('done', false)

Or skip the terminal and run the whole backend in a tab: [browser demo link]

Honest limits

tinbase is alpha (currently v0.6.x). It's built for local development, prototyping, and embedded/browser use — for production, hosted Supabase remains the recommendation, and a tinbase project migrates there unchanged, which is the point of protocol compatibility. Known gaps are documented in the README: no MFA/SSO/phone auth yet, no resumable (TUS) uploads or image transformations, no pgvector, and the engines currently serialize writes over a single connection — fine for dev tools and small apps, not high-concurrency production. The issue tracker is open and good first issues are labeled.