HN Showcase
Back to browse
GitHub Repository

Typescript library to help you migrate away from Supabase

16 starsTypeScript

Replacebase – library to migrate away from Supabase

by fabianlindfors·Feb 25, 2026·6 points·2 comments
Visit ProjectView on HN

AI Analysis

●●SolidSolve My ProblemShip It

Drop-in Supabase API replacement, but early-stage and needs production validation.

Strengths
  • •Genuine friction point: Supabase migration is painful, this directly addresses it.
  • •Framework-agnostic design means integrates with any backend; auth, storage, and realtime all covered.
  • •Early but honest about limitations — author explicitly positions as stepping stone, not final destination.
Weaknesses
  • •Early-stage warning in README signals incomplete features and potential breaking changes.
  • •Replaces one lock-in (Supabase) with another (Replacebase) unless you fully re-architect your backend.
Target Audience

Backend developers migrating away from Supabase

Similar To

PostgREST · Directus · Strapi

Post Description

Hey folks!

There has been a lot of talk recently about the reliability of Supabase and migrating away to other database providers (or even hosting Postgres yourself).

I'm a big proponent of writing actual backend code rather than locking yourself into frameworks like Supabase. If you already built all your client-side code around it though, then migrating is not a trivial task.

Replacebase is designed to help with that. It's a Typescript library that you can plug into actual backend code that exposes a Supabase-compatible API so that you don't have to make significant changes to your frontend.

It's designed to be a stepping stone for further migration, letting you switch database and storage providers and eventually move to a bespoke backend architecture without Supabase lock-in (at which point you can also remove Replacebase!)

Would love your thoughts: https://github.com/specific-dev/replacebase

Similar Projects

Developer Tools●Mid

Spawn – Postgres migration/test build system with minijinja (not vibed)

Edit-in-place components + per-migration snapshotting is a neat practical solution to the classic migration-versus-repeatability tradeoff: you keep readable Git diffs for functions but spawn pins exact component versions into lock.toml and compiles them into atomic SQL transactions. Minijinja macros and JSON-driven data generation make writing repeatable tests and fixtures much less painful. The only obvious limit today is Postgres-via-psql only, but the compilation/snapshot model feels like a real workflow improvement for teams that live in the database.

Niche GemWizardry
Winsaucerer
103mo ago