We are moving to General Availability

General Availability & Positioning

  • Supabase announced GA after ~4 years of beta; message is that the org, support, and success teams are now “ready for any customer profile.”
  • Positioning has shifted from “Firebase alternative” toward “Postgres hosting + tools,” though the Firebase comparison is still used for discoverability and aspiration.
  • New features around performance and security are highlighted, including an Index Advisor extension and related tooling.

Portability vs. Lock‑in

  • One camp argues Supabase is highly portable: it’s “just Postgres,” everything is open source/self-hostable, and migration is a pg_dump away.
  • Critics counter that real lock‑in appears once you rely on Supabase‑specific components (PostgREST, auth/go-true, client‑side DB access) and that running these yourself reduces the value of a managed service.
  • There’s debate over whether Supabase is more or less “standard” than traditional managed Postgres offerings; some say it’s as standard as it gets, others call it a typical BaaS tradeoff (speed now, disentangling later).

Security, RLS, and Architecture

  • Several users are uneasy about exposing Postgres directly to the internet and relying heavily on RLS, especially given limited tooling and testing support.
  • Others point out RLS is secure-by-default once enabled; the main sharp edges are default PostgREST exposure and views that bypass RLS unless carefully configured.
  • Some teams ended up abandoning the “client directly to DB + RLS” pattern in favor of a more traditional API server layer, reducing Supabase-specific architecture.

Self‑Hosting & Infrastructure Experience

  • Self‑hosting reports are mixed: some run multiple instances successfully; others cite unstable Docker updates, heavy idle resource usage, and a monolithic docker‑compose that’s hard to trim down.
  • Requests include a minimal, well-documented self-host config and clearer explanations of each service and non-default setting.

Performance & Latency

  • Experiences range from “fast enough” (tens of ms with regional proximity or Fly.io integration) to “hundreds of ms per query” leading some to migrate DBs elsewhere (e.g., self‑hosted Postgres, Planetscale).
  • Users in China report latency too high for business use and resort to local cloud providers.

Tooling, SDKs, and DX

  • Positive notes on quick MVP launch speed and powerful Postgres features; several happy small-app and startup users.
  • Criticisms focus on:
    • Documentation gaps, fragmented examples, and confusing deprecations (auth-helpers/SSR, SvelteKit, C# and Swift clients).
    • Difficulty authoring and testing RLS policies; calls for better visual analysis tools, policy simulators, and stronger local dev parity.
    • Bugs in edge functions and auth flows causing teams to roll their own APIs/auth.

Pricing & Product Suggestions

  • Many rely on the generous free tier; Supabase says most of the ~1M DBs are free and the tier is “not going anywhere.”
  • Requests include:
    • A cheaper “small projects” paid tier and/or standalone Postgres-only offering.
    • Better OpenID Connect integrations, Prisma-first messaging, opinionated env wiring, and common app templates (e.g., chat/DM).
    • Improved experience for multi-project self-hosting and China-region hosting.