DEV Community: Russel Dsouza

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.

React Native Performance Monitoring: Tools and Techniques for 2026

Russel Dsouza — Tue, 28 Jul 2026 13:42:21 +0000

Flipper is gone (removed as default in RN 0.76). React Native DevTools is the sanctioned replacement.
Track eight metrics — the two most under-monitored are slow frames % and frozen frames %, the closest proxy for "feels laggy."
The pragmatic 2026 production default: Sentry for crashes + performance, optionally layered with Firebase Crashlytics (free redundancy) or Datadog RUM (if you're already on Datadog).
The New Architecture shifts the culprits: TurboModule calls blocking the JS thread, and Fabric commit contention on the UI thread.

The React Native performance monitoring landscape looks nothing like it did two years ago. Flipper is gone as the default debugger. The New Architecture — Fabric, TurboModules, and the bridgeless runtime — is on by default in every fresh app. Hermes is the assumed engine.

If you're shipping in 2026, you need a stack that reflects those changes: dev-time profilers that speak Perfetto and Hermes, production observability that captures slow frames per screen, and a workflow for turning that data into fixes before your App Store rating quietly drops from 4.6 to 4.1.

What "performance" actually means in React Native

React Native has a two-thread execution model, and every performance conversation lives inside it:

The JS thread — business logic, Redux reducers, Animated orchestration, most third-party code.
The UI (main) thread — layout, drawing, gesture recognition, native module execution, useNativeDriver animations.

A janky animation is almost always a UI thread problem. A slow list scroll under load is usually a JS thread problem. A screen that takes three seconds to appear after a tap is likely JS thread — unless it's blocking on a network call, in which case it's a waterfall issue. A frozen screen after login is often a JSI serialization stall.

Monitoring means tracking both threads, tying the data to specific user journeys, and being able to answer three questions:

Is it slow? — objective metrics on frame rate, TTI, startup.
Where is it slow? — which screen, component, native module.
Why is it slow? — flame graphs, network waterfalls, memory pressure.

If your setup only answers question one, you don't have monitoring — you have a smoke alarm.

The eight metrics that matter in 2026

Metric	What it measures	Healthy target
JS FPS	Frame rate on the JS thread	60 fps sustained (120 on ProMotion)
UI FPS	Frame rate on the native main thread	60 fps sustained (120 on ProMotion)
Cold start time	Icon tap to first interactive frame	< 2.0s on mid-tier Android
Warm start time	Time to interactive when backgrounded	< 400ms
TTI	Screen mount → first tap-responsive frame	< 1s per screen
Slow frames %	Frames rendered in > 16.67ms	< 5% per session
Frozen frames %	Frames rendered in > 700ms	< 0.1% per session
JS bundle size	Compressed bundle on first launch	< 2MB gzip

The two most under-monitored metrics are slow frames % and frozen frames % — the closest proxy for the qualitative "laggy." Sentry, Firebase, and Embrace expose them natively; if your stack doesn't, that's the first upgrade to make.

The 2026 tooling stack

Monitoring splits into two phases with different tools: dev-time profiling (finding the problem locally) and production observability (knowing it exists at all).

Development-time tools

Tool	Best for	Notes
React Native DevTools	JS profiling, network, component inspector	Default since RN 0.76. Replaces Flipper.
Hermes Sampling Profiler	Deep JS CPU flame graphs	Export as `.cpuprofile`.
Perfetto / Systrace	System-wide traces across all threads	Android. Best for bridge/native contention.
Xcode Instruments	iOS CPU, memory, energy, Core Animation	Time Profiler + Animation Hitches.
Android Studio Profiler	Java/Kotlin allocations, native memory	Pair with Perfetto.
React DevTools Profiler	Render counts, wasted renders	Ships with RN DevTools.

If a tutorial tells you to install Flipper, it's out of date. Flipper was removed as the default debugger in RN 0.76 and the community plugins are largely unmaintained. React Native DevTools is the replacement, and it's better for JS profiling.

Production observability

Platform	Strengths	Watch out for
Sentry	Crash reporting, integrated perf traces, native + JS stack merging	Sampling costs add up at scale
Firebase Performance	Free, Crashlytics integration, custom traces	Sparse UI, no session replay
Datadog RUM	Backend APM correlation, cohort analysis	Expensive at high MAU
Embrace	Session-first, full journey replay	Smaller ecosystem
Instabug	Bug reporting + perf in one SDK	Duplicates Sentry if you have it
New Relic Mobile	Enterprise-grade infra correlation	Heavier SDK

The pragmatic default for most teams: Sentry for crashes + performance + source-mapped traces, optionally with Firebase Crashlytics as a free redundant crash pipeline, or Datadog RUM if you're already on Datadog.

Minimum-viable production setup

1. Install Sentry with performance monitoring.

npx @sentry/wizard@latest -s -i reactNative

Set tracesSampleRate: 0.2 and enable enableNativeFramesTracking: true and enableAutoPerformanceTracing: true. Native frames tracking is what gives you slow/frozen frame percentages per screen.

2. Instrument navigation. Wrap your app with Sentry's navigation integration so every screen transition becomes a labelled transaction. Without this, traces are anonymous and useless.

3. Upload source maps on every release. Untranslated stack traces are worthless. Bake source map upload into CI so every TestFlight or Play build has readable traces waiting.

4. Add custom spans around slow operations. Any function over 100ms — cache hydration, a DB query, a large image decode — gets a manual span. This turns "screen X is slow sometimes" into "screen X is slow because recipe hydration takes 800ms on cold launch."

5. Set alerts for regressions:

Crash-free session rate below 99.5%
P75 cold start rising > 20% between releases
Slow frame % above 8% on any top-10 screen

A real diagnostic walkthrough: "the feed screen is laggy"

Step 1: Confirm in production data

Filter to the screen, look at P75 and P95 of slow frames per session. If P75 is fine and P95 is bad, it's a device-tier issue — likely mid-tier Android under a specific data condition. Note the device and OS distribution of the worst sessions.

Step 2: Reproduce on the right hardware

Never diagnose Android performance on an iPhone 15 Pro. Grab a Pixel 6a or a mid-tier Samsung and reproduce there. Enable the perf overlay for live JS FPS and UI FPS.

Step 3: Capture a trace

For JS-thread issues: React Native DevTools → Performance tab → record the interaction. Look for long JS tasks (> 50ms bars), high re-render counts, serialization work.

For UI-thread issues on Android: capture a Perfetto trace. Look for main-thread frames overflowing 16.67ms, and whether the overflow is in Choreographer#doFrame or in native module calls.

Step 4: Isolate the offender

Common culprits, ranked by frequency in 2026 codebases:

A FlatList with heavy renderItem work — no memoization, inline arrows. Fix: memoize the row, stabilize props, add getItemLayout if heights are known.
A large state slice re-rendering the whole tree — a selector returning new object identity every time. Fix: narrow the selector, add shallow comparison.
An image decode blocking the UI thread — full-res images in small views. Fix: server-side resize, expo-image with contentFit.
A synchronous AsyncStorage migration on cold start — reading 5MB before render. Fix: defer via InteractionManager.runAfterInteractions, or MMKV with lazy hydration.
A third-party analytics SDK spawning threads on startup — 200–400ms blocks. Fix: initialize lazily after first frame.

Step 5: Verify in a canary

Ship behind a flag or to a beta cohort. Compare P75 slow-frame % on the screen before and after. If the number doesn't move, the fix isn't the fix.

The New Architecture changes what you monitor

Under the old bridge, the biggest sinkholes were JSON serialization between JS and native, visible in traces as huge queues. The New Architecture's synchronous, typed JSI calls mostly remove that class of problem — but introduce two new ones:

Synchronous TurboModule calls that block the JS thread. A native module doing 50ms of I/O now blocks JS directly, where it used to buffer through the async bridge.
Fabric commit contention on the UI thread. Shadow-tree commits are more efficient on average but spike sharply when a large tree diff lands — watch navigation transitions where the whole screen tree re-mounts.

Modern Sentry SDKs instrument both Fabric commits and TurboModule calls when auto-performance tracing is on. On an older SDK, upgrade — you'll see spans you didn't have before.

Bundle size and startup — the fixes that compound

Startup time is the metric most correlated with day-1 retention, and the one most engineers stop optimizing after the first release.

Enable Hermes. If you're not on it, you're leaving 30–50% of cold-start performance on the table.
Precompile Hermes bytecode. Ship .hbc, not .js. RN does this for release builds — verify it.
Ship inline requires on Android. inlineRequires: true in Metro defers module evaluation until first use, cutting 200–500ms on large apps.
Split third-party SDKs. Anything not needed in the first second — analytics, remote config, feature flags — initializes after InteractionManager.runAfterInteractions.
Measure with production RUM, not local. Cold start on your dev machine is meaningless. Trust P75 from real devices.

Track JS bundle size release-over-release. A 100KB regression per release compounds fast.

FAQ

Best free monitoring tool in 2026? Firebase Performance + Crashlytics. Automatic startup and HTTP traces, custom traces, native crash reporting, all free up to a generous tier. Limitations: sparse UI, no session replay — most teams add Sentry for deeper diagnostics.

Is Flipper still usable? No — removed as default in RN 0.76, plugins unmaintained. Use React Native DevTools, plus Perfetto (Android) and Xcode Instruments (iOS) for native profiling.

How do I measure startup time in production? Sentry's enableAppStartTracking: true, or Firebase's automatic _app_start trace. Track P75 cold start — the average hides regressions behind a few fast flagship sessions.

What FPS should an app maintain? 60 fps sustained on both threads (120 on ProMotion). Track slow frames (> 16.67ms) as a percentage and aim under 5% per session.

Do I need separate monitoring for the New Architecture? Same metrics, different culprits — TurboModule calls and Fabric commit contention. Any modern SDK instruments both automatically; just don't run a pre-GA-era SDK.

The takeaway

The dev-time story is React Native DevTools plus platform-native profilers (Perfetto, Instruments). The production story is Sentry as the default, with Firebase Crashlytics as free redundancy or Datadog RUM for existing Datadog teams.

The bigger shift is philosophical: performance is a metric you monitor continuously, not a project you do once. The teams shipping the smoothest apps in 2026 have slow-frame alerts wired to Slack, source maps on every release, and a P75 startup dashboard someone actually looks at each Monday.

I write more about how we handle this in AI-generated React Native apps at RapidNative.

What's your current monitoring stack — and what's the worst "laggy screen" bug you've tracked down? Mine was a 5MB AsyncStorage migration running on every cold start.

Why Supabase local dev needs 2.3 GB of Docker — and how we got it to 58 MB

Russel Dsouza — Fri, 24 Jul 2026 10:38:36 +0000

supabase start runs the production architecture on your laptop: 12 containers, 2,291 MB on disk, 1,626 MB RAM under load
Those services are mostly protocol translators — and protocols can be reimplemented
We rebuilt the surface as one process: pure (Request) ⇒ Response handlers on a swappable Postgres engine
Result: a 58 MB executable, ~2 s cold start, and the official supabase-js SDK passing 168/168 integration tests unchanged
Side effect: the same backend runs inside a browser tab

Part 1: Where the 2.3 GB goes

Run supabase start on a fresh machine and watch docker ps fill up. What you're looking at is Supabase's cloud architecture, faithfully reproduced locally — which is precisely the problem. Each box in their production diagram becomes a container on your laptop:

┌────────────────────────────────────────────────┐
│  supabase start                                │
│                                                │
│  kong          → API gateway / routing         │
│  postgrest     → REST API over Postgres        │
│  gotrue (auth) → JWTs, OAuth, magic links      │
│  realtime      → WebSockets (Elixir/Phoenix)   │
│  storage-api   → file storage over Postgres    │
│  imgproxy      → image transforms              │
│  edge-runtime  → Deno functions                │
│  studio        → dashboard (Next.js)           │
│  postgres-meta → introspection API for Studio  │
│  logflare      → log aggregation               │
│  vector        → log shipping                  │
│  db (postgres) → the actual database           │
└────────────────────────────────────────────────┘

Each service ships as its own image with its own runtime — an Elixir VM here, a Deno runtime there, Node for Studio, Go for auth. None of it is waste in production: these are independently scalable services doing real jobs across a fleet.

But locally, every one of those runtimes is overhead for a single developer making requests from localhost. The measured cost:

	Install footprint	Memory under load
Supabase local (12 containers)	2,291 MB	1,626 MB
tinbase (single binary)	92 MB	66 MB
tinbase (native, via npx)	36 MB	100 MB

And that's before the Docker Desktop tax on macOS and Windows, or environments where Docker isn't available at all: CI sandboxes, cloud IDEs, school machines, a phone.

Part 2: The key observation — it's protocols all the way down

Here's what makes the whole thing tractable. Your app never talks to those containers directly. It talks to documented HTTP and WebSocket protocols through supabase-js:

/rest/v1 speaks the PostgREST grammar — ?select=*,author:users(name)&done=eq.false
/auth/v1 speaks GoTrue's API — signup, OTP, PKCE, refresh tokens
/storage/v1 speaks the Storage API
Realtime speaks the Phoenix channel protocol over WebSockets
/functions/v1 invokes edge functions

A protocol doesn't care what implements it. PostgREST is ~"take this URL grammar, compile it to SQL, run it with the caller's JWT claims applied." GoTrue is "manage users in auth.users, mint JWTs." These are translation layers over Postgres — and translation layers can be reimplemented in-process.

What you cannot fake is Postgres itself. RLS evaluation, auth.uid() in policies, jsonb operators, triggers, ON DELETE CASCADE — behavior differences there produce the worst kind of bug: works locally, breaks in production. So that became the design rule:

Reimplement the translation layers. Never reimplement Postgres.

Part 3: The architecture — one fetch handler

Every tinbase service is a pure function: (Request) ⇒ Response. No sockets owned, no ports assumed, no filesystem requirements baked in. The whole backend composes into a single handler:

supabase-js (unmodified)
        │
        ▼
one (Request) ⇒ Response handler
  ├─ /rest/v1      → PostgREST grammar → SQL
  ├─ /auth/v1      → GoTrue flows → auth schema
  ├─ /storage/v1   → Storage API
  ├─ Realtime      → Phoenix protocol
  ├─ /functions/v1 → in-process handlers
  └─ /_/           → Studio dashboard
        │
        ▼
DbEngine adapter
  ├─ native → embedded Postgres 17
  ├─ wasm   → PGlite (Postgres compiled to WASM)
  └─ pg-mem → pure JS, in-memory (subset)

The REST layer parses the PostgREST grammar and compiles it to parameterized SQL — embedded resources become joins, filters become WHERE clauses — then executes with the request's JWT claims set, so your RLS policies run exactly as Postgres intends:

-- every request runs with claims applied, e.g.:
SET LOCAL request.jwt.claims = '{"sub":"<user-uuid>","role":"authenticated"}';
-- so this policy Just Works, locally and in prod:
CREATE POLICY "own todos" ON todos
  FOR SELECT USING (auth.uid() = user_id);

Realtime does the same per-subscriber: change events are filtered through RLS before delivery, so a user only receives events for rows they're allowed to see.

Things production Supabase does with Postgres extensions get reimplemented natively instead, because a single process can just... do them:

database webhooks — no pg_net
cron.schedule() — no pg_cron
a pgmq subset — no pgmq

Part 4: The consequences of "pure fetch handler"

This constraint looked academic. It turned out to be the most productive decision in the project.

In Node, the handler binds to a port and becomes an ordinary HTTP + WebSocket server:

npx tinbase start
# ~2 seconds → http://127.0.0.1:54321, Studio at /_/

As a binary, it compiles to a single 58 MB executable — no Node, npm, or Docker on the target machine. That's the CI story: download one file, run it, test against real Postgres.

In a browser, you hand the same handler to supabase-js as a custom fetch:

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

const tin = await createTinbase({ engine: 'wasm' })   // PGlite under the hood

const supabase = createClient('http://tinbase.local', ANON_KEY, {
  global: { fetch: tin.fetch }   // ← the entire backend is this function
})

// no server anywhere; Postgres is running inside the tab
await supabase.from('todos').insert({ title: 'hello from a browser tab' })

Database included, running in-process. No server, no cloud. (Live demo: tinbase.dev/browser.)

We didn't set out to build a curiosity — this was the original requirement. tinbase came out of building RapidNative, where we needed a full dev stack — database, auth, storage, realtime — running in browsers and on phones with no VMs behind it. The single-process backend fell out of that constraint; replacing local Docker was the happy accident.

Part 5: How we know it's compatible

Claiming "Supabase-compatible" is easy. Our test is blunt: run the official supabase-js SDK's integration suite against tinbase, unmodified.

Current score: 168/168 passing, across both the native Postgres engine and the WASM engine. That covers the REST grammar (filters, embedded resources, RPC), the auth flows (email/password, anonymous, OTP, magic links, recovery, OAuth with PKCE), storage, and realtime's postgres_changes / broadcast / presence.

Migration compatibility is the other half. tinbase reads supabase/migrations/*.sql and seed.sql exactly like the Supabase CLI, tracked in the same table — so the exit path is: push the same files to hosted Supabase and keep going. Compatibility that doesn't include leaving isn't compatibility.

What this doesn't claim

tinbase is alpha (v0.10.0), and honesty is cheaper than a disappointed issue tracker:

Not production-ready. It's for local dev, prototypes, and embedded/browser use.
Not 100% of the surface. It covers the common paths (the test suite defines "common"); edges remain.
Not a Supabase replacement. It's the local half of a workflow that ends at hosted Supabase. Real Postgres in production is still the right call.
pg-mem is a subset. The pure-JS engine trades fidelity for zero-WASM environments; use native or PGlite when you can.

Try the numbers yourself

npx tinbase start

Repo (MIT): github.com/tinbase/tinbase — the benchmark methodology is on the site if you want to reproduce the table above.

If you've solved local-Supabase pain a different way — Nix, compose tricks, pg_regress heroics — I genuinely want to hear it in the comments. And if you try the browser engine, tell me what you build with it.

Introducing tinbase — local Supabase without Docker (one process, real Postgres)

Russel Dsouza — Thu, 23 Jul 2026 10:04:50 +0000

Supabase local dev = a 12-container, 2.3 GB Docker stack. tinbase serves the same APIs from one 58 MB process. No Docker.
It's real Postgres 17 — RLS, auth.uid(), jsonb, triggers, foreign keys all behave like hosted Supabase.
The official supabase-js SDK works unchanged (168/168 integration tests pass).
The whole backend — database included — can run inside a browser tab.
Open source, MIT. Try it: npx tinbase start

The problem

You know the drill. supabase start, then Docker pulls Postgres, PostgREST, GoTrue, Storage, Realtime, Studio... twelve containers, 2.3 GB on disk, ~1.6 GB of RAM under load. All you wanted was to run your app locally.

I love Supabase. I did not love paying a 2 GB tax to write a todo app on the train.

What tinbase does instead

One process. Same wire protocols:

	Install footprint	Memory under load
Supabase local (12 containers)	2,291 MB	1,626 MB
tinbase (single binary)	92 MB	66 MB
tinbase (native)	36 MB	100 MB

npx tinbase start

~2 seconds later you're serving requests. There's also a single 58 MB executable that needs no Node, npm, or Docker on the target machine.

Your code doesn't change

This is the whole point. tinbase implements the PostgREST query grammar, GoTrue auth flows, the Storage API, and the Realtime Phoenix protocol — verified by running the official SDK against it:

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

const supabase = createClient('http://127.0.0.1:54321', ANON_KEY)

await supabase.auth.signUp({ email, password })
await supabase.from('todos').insert({ title: 'hello' })

const { data } = await supabase
  .from('todos')
  .select('*, author:users(name)')
  .eq('done', false)

supabase.channel('feed')
  .on('postgres_changes',
      { event: 'INSERT', schema: 'public', table: 'todos' },
      handleNewTodo)
  .subscribe()

No fork of the SDK. No wrapper. No different query language. RLS runs with your JWT claims applied, so auth.uid() policies work as-is — and Realtime does per-subscriber RLS filtering, so users only get change events for rows they can see.

Auth covers email/password, anonymous, OTP, magic links, password recovery, and OAuth (Google/GitHub + generic) with PKCE. Edge Functions run in-process via supabase.functions.invoke(). Webhooks, cron.schedule(), and a pgmq subset are in there natively — no pg_net/pg_cron/pgmq extensions to install. And a Supabase-Studio-style dashboard ships at /_/.

The weird part: it runs in a browser tab

Every service in tinbase is a pure (Request) ⇒ Response fetch handler on top of a swappable DB engine:

supabase-js (unmodified)
        │
        ▼
one (Request) ⇒ Response handler
  ├─ /rest/v1      (PostgREST)
  ├─ /auth/v1      (GoTrue)
  ├─ /storage/v1   (Storage)
  ├─ Realtime      (WebSocket)
  ├─ /functions/v1 (Edge Fns)
  └─ /_/           (Studio)
        │
        ▼
DbEngine adapter
  ├─ native  → embedded Postgres 17
  ├─ wasm    → PGlite (Postgres in WASM)
  └─ pg-mem  → pure JS, in-memory

In Node, that handler is an HTTP + WebSocket server. In the browser, you hand it to supabase-js as a custom fetch — and the entire backend, Postgres included, runs in-process in the tab. No server. No cloud. You can play with it at tinbase.dev/browser.

It's not a dead end

tinbase reads supabase/migrations/*.sql and seed.sql exactly like the Supabase CLI, tracked in the same table. Outgrow it? Push the same files to hosted Supabase and keep moving. You can also point it at a Postgres you already run with --database-url.

Why we built it

tinbase came out of building RapidNative and lifo, with a stubborn goal: run an entire dev stack — database, auth, storage, realtime — in the browser and on phones, with no VMs and no cloud behind it. Cutting the backend down to a single process was step one; making that same process run inside a tab was step two. Somewhere along the way it turned into a genuinely useful Docker-free replacement for local Supabase dev, so we open-sourced the whole thing (MIT).

Honest caveats

It's alpha (v0.10.0). Built for local dev, prototypes, and embedded/browser use — not production. 168/168 integration tests pass across both engines, but if you hit an API edge we haven't covered, open an issue.

Try it

npx tinbase start

GitHub: github.com/tinbase/tinbase

What would you build if your whole backend fit in a browser tab? Drop a comment — especially if you try the browser engine, I want to see what you make with it. 🚀

How to Publish Your Lovable App to the App Store (Without Rebuilding It Yourself)

Russel Dsouza — Wed, 22 Jul 2026 09:43:09 +0000

Lovable builds a web app. The App Store distributes native apps. That's a category gap, not a skill gap.
WebView wrappers feel wrong (scroll momentum, transitions, haptics, back gesture) and risk rejection under App Store Guideline 4.2.
The real fix is a React Native + Expo rebuild — plus certificates, provisioning profiles, signing keys, screenshots, and metadata.
If your Lovable app uses Supabase, a native rebuild can point at the same project. No migration needed.

You built something in Lovable over a weekend. It works. You sent the link to friends and they said "wait, you built this?"

Then someone asked: "Is it on the App Store?"

That's where most Lovable projects stall.

Why you can't submit a Lovable app to the App Store directly

Building an app and shipping an app are two different projects.

Lovable is excellent at the first one. But the App Store distributes native apps, and Lovable produces a web app. That's not a skill gap — it's a category gap.

To publish, you need:

An Apple Developer account ($99/year)
A bundle identifier
A distribution certificate and provisioning profile
A signed .ipa binary
Screenshots at every required device size
A privacy nutrition label and data-usage disclosure
A human reviewer who might say no

None of that comes out of a web app builder.

Why wrapping it in a WebView doesn't work

The obvious shortcut is a wrapper: put the web app in a native shell and ship the shell. Two problems.

It feels wrong. Scroll momentum is off. Transitions don't match the platform. Text inputs behave like a browser instead of a native keyboard. No haptics. The back gesture doesn't do what a thumb expects. Users can't name it, but they register it as "website in a box."

Apple notices too. Guideline 4.2 exists specifically for repackaged websites that don't provide enough native value. Plenty of wrappers slip through, but you're rolling dice on review — and each rejection costs a full cycle.

What a real conversion actually involves

The honest answer is a native rebuild: React Native + Expo, real navigation, real gestures, real device APIs (camera, push, the rest).

Technically that's the right call. Practically it's where projects die — you spent two days building the product and you're now looking at learning the entire Apple release toolchain, or paying someone who already has.

That mismatch is the whole problem. The building was fun and fast. The shipping is neither.

If you'd rather hand that part off, RapidNative converts Lovable apps to React Native and handles the full submission — signing, screenshots, metadata, the lot. You get a preview build on your device first, the full Expo source code afterward (no lock-in), and rejections are handled at no extra cost until you're approved. Typical turnaround is 1–2 weeks.

Worth noting for anyone doing this themselves too: if your Lovable app already talks to Supabase, you don't need to migrate anything. Point the React Native app at the same project and your data layer is done.

The takeaway

Building and shipping are separate problems. Being good at one tells you nothing about how hard the other will be.

Lovable made building dramatically easier. Apple's requirements haven't moved — and Google added a 12-tester closed-testing gate on top.

If your app is stuck one wall away from the store, that's not a verdict on your product. It's just a different category of work than the one you finished.

Been through App Store submission yourself? Which screen broke you? Mine was the privacy nutrition label.

DEV Community: Russel Dsouza

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

The three failure modes

Version drift, in detail

Realtime during deploys

Storage behind a proxy

What this actually implies

If you're running it now

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

The three decisions

Local: the one worth changing

Staging: the one people skip

Production: highest stakes, usually-correct default

The mistake

Worked examples

The short version

Migrating a Supabase Local Dev Project to Tinbase in 10 Minutes

Prerequisites

Step 1: install the binary

Step 2: dump your Supabase schema

Step 3: import into Tinbase

Step 4: point your app at it

Step 5: verify

Rolling back

What doesn't migrate cleanly

Why bother

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

The parts that are actually mechanical

Build and submit without touching Xcode

The Google Play track model

Metadata as a file, not a form

Wiring it to a tag

What should stay manual

The part that compounds

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

The Four Buckets

Technical Metrics That Are Actually Product Metrics

The Stack I Actually Use in 2026

The One Instrumentation Pattern That Scales

Metrics I Have Deleted From Every Dashboard

Privacy: The 2026 Baseline

Where to Go From Here

Best React Native Starter Templates in 2026 (Compared)

Best React Native Starter Templates in 2026 (Compared)

What makes a good React Native starter template?

What developers usually search for

Popular React Native starter templates

Expo Router Starter

Ignite

React Native Boilerplates

gluestack-ui Pro

Questions to ask before choosing a starter template

Final thoughts

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

Introducing gluestack-ui Pro

55+ Ready-to-use Screens

The Codebase & Architecture

Modern Tech Stack

Seamless Customization

Wrapping Up

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

The problem

Why Supabase compatibility instead of yet another backend

The architecture

The hard parts

The numbers

What it looks like in practice

Honest limits

Links

React Native Performance Monitoring: Tools and Techniques for 2026

What "performance" actually means in React Native

The eight metrics that matter in 2026

The 2026 tooling stack

Development-time tools

Production observability

Minimum-viable production setup

A real diagnostic walkthrough: "the feed screen is laggy"

Step 1: Confirm in production data

Step 2: Reproduce on the right hardware

Step 3: Capture a trace