We are moving to General Availability
Supabase has announced that its managed Postgres platform and surrounding open source tooling are now in general availability after four years in beta, positioning itself less as a generic “Firebase alternative” and more as “Postgres plus useful tools.” Commenters praise its fast time‑to‑launch, generous free tier, self‑hostability, and new features like an Index Advisor, but raise concerns about perceived lock‑in, RLS‑centric security patterns, latency in some regions, and rough edges in self‑hosting, documentation, and SDK support. Many see strong potential for production use—especially when treating Supabase primarily as a standard Postgres host—while urging better tooling, clearer migration paths, and more polished language- and framework-specific integrations.
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.