Supabase Alternatives in Europe: GDPR-Compliant BaaS Options (2026)

Supabase has become the default Backend-as-a-Service for indie hackers, startups, and product teams who want Postgres, Auth, Storage, and Edge Functions without operating six different services. It is genuinely excellent — and that is exactly why so many European teams are now looking for an alternative.

The problem is not Supabase the product. The problem is the legal plumbing underneath it. Supabase is a US-incorporated company that hosts projects primarily on AWS regions. Even when you choose the Frankfurt (eu-central-1) region, you are still operating under a US parent company subject to the CLOUD Act and the Schrems II fallout from the Schrems II ruling of 2020. For a law firm, a hospital, a public-sector app, or a B2B SaaS selling into regulated industries, that is often a blocker — regardless of how good the developer experience is.

This guide covers the realistic 2026 options: what Supabase actually gives you, why teams move away, and the five alternatives worth evaluating — including a composable stack on DanubeData (Falkenstein, Germany) that lands between €30 and €50 per month versus Supabase Team at $599.

What Supabase Actually Gives You

Before comparing alternatives, let us be precise about what you are replacing. Supabase is not one product — it is a curated bundle of open-source components glued together with a clean dashboard:

• Postgres database — a managed PostgreSQL instance (versions 15–17) with extensions enabled out of the box (pgvector, PostGIS, pg_cron, pg_graphql).
• PostgREST auto-generated API — every table and view is automatically exposed as a REST endpoint, gated by Row-Level Security (RLS) policies.
• GoTrue authentication — email/password, magic links, OAuth providers, phone OTP, and (in Pro) SAML SSO. Issues JWTs that PostgREST uses to evaluate RLS.
• Storage — an S3-compatible object store with RLS-style policies on top.
• Edge Functions — Deno-based serverless functions running on Cloudflare Workers / Deno Deploy infrastructure.
• Realtime — a WebSocket server that streams Postgres WAL changes and broadcast messages to connected clients.
• Vector — pgvector on top of your Postgres, surfaced as a first-class API in the dashboard.

The genius of Supabase is not any single component — it is the integration. Your JWT from Auth flows into Postgres, your RLS policies gate both the REST API and the Storage bucket, and your Edge Functions can call the database with the caller's identity still attached. Replicating that coherence is the actual job of any alternative.

Why European Teams Look Elsewhere

1. Schrems II and the CLOUD Act

In July 2020 the Court of Justice of the EU invalidated Privacy Shield in the Schrems II ruling, declaring that US surveillance law (FISA 702, Executive Order 12333) is incompatible with the GDPR's level of protection for personal data. The 2023 EU-US Data Privacy Framework patched the legal gap for certified US companies, but the underlying reality has not changed: a US-headquartered company can be compelled to hand over data stored anywhere in the world under the CLOUD Act, even if the data sits in Frankfurt.

Supabase is a Delaware C-corp. Choosing the eu-central-1 region solves data residency. It does not solve data sovereignty.

2. Pricing at Scale

Supabase's free tier is generous for prototypes. The trouble starts at production:

• Pro: $25/project/month, 8 GB database, 100 GB storage, 250 GB egress.
• Team: $599/month, SOC 2, SAML SSO, read replicas, 24/7 support.
• Compute add-ons: +$10 to +$3,730/month depending on the instance size. A 16 GB / 8 vCPU Postgres is around $410/month on top of Pro.
• Bandwidth overage: $0.09 per GB once you pass the included allowance.

A real-world SaaS with moderate traffic, one 16 GB Postgres, and 2 TB of egress is $600–$900/month on Supabase. The same workload on a composable European stack is in the €30–€80 range.

3. "Magic" Abstractions You Cannot Tune

PostgREST is excellent until it is not. When you need a stored procedure with a non-trivial return shape, a LISTEN/NOTIFY pipeline, or a replication slot for CDC into an external data warehouse, the managed platform starts fighting you. Teams outgrow the abstraction and want direct SUPERUSER-ish access to their own Postgres.

4. Vendor Lock-in on "Open Source"

Supabase is open source, and you can self-host the entire stack. In practice, self-hosting Supabase is operationally heavy — you are running GoTrue, PostgREST, Kong, Storage, Realtime, pg_graphql, Studio, and the Postgres itself, plus their CI-built Docker images. Most teams that go this route end up running a composable stack anyway.

The Five Realistic Alternatives

Option 1: Self-Host Supabase on a European VPS

The most literal alternative. You take the supabase/supabase Docker Compose bundle and run it on a VPS in Falkenstein. You keep the familiar API surface and can still use @supabase/supabase-js unchanged.

• Pros: identical developer experience, full data sovereignty, no CLOUD Act exposure, linear pricing.
• Cons: you operate the full stack — backups, upgrades, TLS, SMTP, storage redundancy. Expect 4–8 hours/week of operational overhead for a production deployment.
• Best for: teams who love the Supabase API and have one SRE on staff.

A reasonable starting footprint: a 4 vCPU / 8 GB VPS (€17.99 on DanubeData) plus S3-compatible object storage for the storage service (€3.99) — around €22/month for a single-region deployment.

Option 2: Appwrite (Self-Hosted in Europe)

Appwrite is the most popular open-source BaaS after Supabase. It uses MariaDB (not Postgres) under the hood, with its own abstraction over documents, collections, and attributes. The developer experience is mobile-first — Appwrite started as a Firebase alternative rather than a Supabase clone.

• Auth: 30+ OAuth providers, magic URLs, phone, anonymous sessions.
• Databases: document-style API on top of MariaDB with relationship support.
• Storage: built-in with image transformations.
• Functions: Node, Python, PHP, Ruby, Dart, Go, Swift, Kotlin runtimes.
• Realtime: WebSocket subscriptions on collections, documents, and events.

Appwrite Cloud has an EU region (Frankfurt) but the company is US/Israeli — same Schrems II questions as Supabase. The self-hosted route is fully sovereign and runs cleanly on a single 8 GB VPS.

Best for: teams who want a more opinionated, mobile-friendly BaaS and do not need raw SQL access.

Option 3: Nhost (European-Friendly Hasura Stack)

Nhost is the closest "Supabase but European" on the managed-cloud side. Nhost is incorporated in Sweden, and its managed cloud runs on AWS eu-central-1 (Frankfurt) and eu-west-1 (Ireland). Technically, Nhost replaces PostgREST with Hasura GraphQL — you get a GraphQL API auto-generated from your Postgres schema, with permissions evaluated per row and per column.

• Database: managed Postgres.
• Auth: Hasura Auth (their fork of the old Firebase-style JWT).
• Storage: S3-backed with Hasura permission integration.
• Functions: Node.js serverless functions.
• API: GraphQL first, REST on request.

Being Swedish does not by itself defeat the CLOUD Act — Nhost's infra still runs on AWS — but it meaningfully reduces the cross-Atlantic question. Self-hosting Nhost is supported and well documented.

Best for: teams who prefer GraphQL over REST and want a cloud-managed option that is at least EU-incorporated.

Option 4: PocketBase (Single Binary)

PocketBase is a Go binary that ships database, auth, storage, realtime, and an admin UI in one executable weighing about 30 MB. Underneath, it uses SQLite — which sounds like a toy until you realize SQLite in WAL mode with Litestream replication handles tens of thousands of writes/second on modest hardware.

• Database: SQLite with JSON fields, relations, triggers.
• Auth: email, OAuth (Google, Apple, GitHub, etc.), OTP.
• Realtime: SSE on collections.
• Storage: local disk or S3.
• Extensibility: JavaScript hooks (JSVM) or Go plugins.

PocketBase has the lowest operational overhead of any option on this list. A single VPS, a systemd unit, a backup to S3 every hour — that is the entire stack. It is the right answer for indie projects, internal tools, and early-stage products that may later migrate to Postgres.

Best for: solo developers, MVPs, internal tools, and anything under ~50k monthly active users.

Option 5: Compose Your Own Stack on DanubeData

The most flexible option — and the one that most closely mirrors Supabase's actual architecture without the abstractions. You assemble the primitives yourself, each as a managed service:

• Managed PostgreSQL (€19.99/mo) — the database, with extensions, automated snapshots, and a replica-ready architecture.
• S3-compatible Object Storage (€3.99/mo, 1 TB included) — the storage layer.
• Serverless Containers (€5/mo, scale-to-zero Knative) — the Edge Functions equivalent. Deploy a Dockerfile or a Git repo, it scales from 0 to N and back.
• VPS (€4.49+/mo) — for Authentik or Keycloak (self-hosted identity provider) and PostgREST if you want the Supabase-style auto-API.

Everything sits in Falkenstein, Germany, operated by a Romanian company under EU law. No US parent, no CLOUD Act exposure, no Schrems II hedging. Total monthly cost for a production stack: around €30–€50/month.

Feature & GDPR Comparison

Pricing Reality Check

Here is the same workload — one mid-size SaaS with ~50,000 MAU, 16 GB Postgres, 500 GB storage, 2 TB monthly egress, and a handful of serverless endpoints — priced across every option:

The composable stack gives you managed Postgres (with automated snapshots and operated failover), S3 object storage, and a real serverless runtime — for roughly 1/12th the price of Supabase Team, with no US-entity legal overhang.

Building the Supabase Equivalent on DanubeData

If you want the full Supabase experience — Postgres + auto-generated REST API + Auth + Storage + Functions + Realtime — on a European, GDPR-clean stack, here is the concrete recipe.

Architecture Overview

                    ┌──────────────────────────┐
                    │  Your Frontend (Vue/React)│
                    └────────────┬─────────────┘
                                 │ HTTPS + JWT
                    ┌────────────▼─────────────┐
                    │  PostgREST (on VPS)       │ ← auto REST API from Postgres
                    │  + Authentik (on VPS)     │ ← OAuth/OIDC identity
                    └────────────┬─────────────┘
                                 │
              ┌──────────────────┼────────────────────┐
              │                  │                    │
   ┌──────────▼──────────┐  ┌────▼──────────┐  ┌─────▼────────────┐
   │ Managed Postgres    │  │ Object Storage│  │ Knative Serverless│
   │ (€19.99/mo)         │  │ (S3, €3.99)   │  │ (€5/mo per fn)    │
   │ + RLS policies      │  │ + signed URLs │  │ Deno / Node / Go  │
   └─────────────────────┘  └───────────────┘  └──────────────────┘

Step 1: Provision Managed Postgres

Create a PostgreSQL 17 instance on DanubeData. Out of the box you get pgcrypto, pgvector, uuid-ossp, and pg_stat_statements. The management API hands you:

• A hostname like pg-abc123.postgres.danubedata.ro.
• A TLS certificate bundle (CA).
• An owner user for DDL.
• A reader endpoint (if you add a replica).

Create a dedicated role for the API layer and enable RLS on every table:

-- One-time setup
create role api_anon nologin;
create role api_authenticated nologin;
create role api_service_role nologin bypassrls;

-- A tenant-scoped table
create table tenants (
    id uuid primary key default gen_random_uuid(),
    owner_id uuid not null,
    name text not null,
    created_at timestamptz default now()
);

alter table tenants enable row level security;

create policy "owners see their tenant"
    on tenants for select
    to api_authenticated
    using (owner_id = auth.uid());

create policy "owners update their tenant"
    on tenants for update
    to api_authenticated
    using (owner_id = auth.uid());

Step 2: Deploy PostgREST on a VPS

PostgREST is the same component Supabase uses. A €4.49 VPS handles tens of thousands of requests per second:

# /etc/postgrest.conf
db-uri = "postgres://postgrest_auth@pg-abc123.postgres.danubedata.ro:5432/app?sslmode=verify-full"
db-schemas = "api"
db-anon-role = "api_anon"
jwt-secret = "$(openssl rand -base64 48)"
jwt-role-claim-key = ".role"
server-port = 3000

Drop PostgREST behind Caddy for automatic TLS and you have Supabase's REST layer.

Step 3: Add Authentik for Auth

Authentik is a mature open-source identity provider (OIDC, SAML, LDAP, passkeys, TOTP). Run it on the same VPS via Docker Compose. Configure it to issue JWTs with a role claim of api_authenticated and a sub claim that becomes auth.uid() in your RLS policies.

-- Postgres helper so RLS policies can read the JWT
create schema auth;
create function auth.uid() returns uuid language sql stable as $$
    select nullif(current_setting('request.jwt.claims', true)::json->>'sub', '')::uuid;
$$;

Alternative: self-host GoTrue itself — it is just a Go binary — for pixel-perfect compatibility with @supabase/supabase-js.

Step 4: Wire Up S3-Compatible Storage

Create an Object Storage bucket on DanubeData (€3.99/mo for 1 TB included). You get an endpoint, access key, and secret. Any S3 SDK works:

// Node.js
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({
    endpoint: "https://s3.danubedata.ro",
    region: "eu-central",
    credentials: {
        accessKeyId: process.env.DD_ACCESS_KEY,
        secretAccessKey: process.env.DD_SECRET_KEY,
    },
    forcePathStyle: false,
});

// Upload a user avatar
await s3.send(new PutObjectCommand({
    Bucket: "dd-42-avatars",
    Key: `users/${userId}.jpg`,
    Body: fileStream,
    ContentType: "image/jpeg",
}));

For Supabase-style RLS on storage, generate time-limited pre-signed URLs from a PostgREST RPC that first checks Postgres permissions — the pattern is ~40 lines of SQL + a short TypeScript helper.

Step 5: Edge Functions via Knative

DanubeData's Serverless Containers (Knative under the hood) scale from zero to N on traffic. Deploy a Deno, Node, Python, or Go function from a Git repo or a Dockerfile. Cold start is 200–800 ms depending on the runtime; warm requests are native-fast.

# danube.yaml for a simple webhook handler
name: stripe-webhook
source: git
repo: https://github.com/youracme/stripe-webhook
env:
  STRIPE_WEBHOOK_SECRET: {{ secret "stripe-webhook-secret" }}
  DATABASE_URL: {{ secret "postgres-url" }}
scale:
  min: 0
  max: 10

Your function runs in Falkenstein, behind your own *.fn.danubedata.ro domain (or a custom domain with automatic TLS), and receives the caller's JWT in the Authorization header — same pattern as Supabase Edge Functions.

Step 6: Realtime (Optional)

You have three realistic choices:

• Postgres LISTEN/NOTIFY + SSE: a 100-line serverless function that maintains a LISTEN connection and streams events to clients over Server-Sent Events. Good for up to a few thousand concurrent connections.
• Self-host supabase/realtime: the exact same Elixir server Supabase uses, runs on a small VPS, streams WAL changes over WebSocket.
• Centrifugo: a standalone realtime messaging server, very fast, handles millions of connections on commodity hardware.

Putting It Together

The complete Supabase-equivalent footprint on DanubeData:

Compare that to Supabase Pro + a 16 GB compute add-on at ~$450, or Team at $599+, and the delta over 12 months is €5,000–€7,000 of budget back in your pocket — plus clean GDPR posture.

Migrating from Supabase

Supabase is built on standard Postgres, which makes migration mercifully straightforward:

1. Dump: pg_dump --no-owner --no-acl --schema=public --data-only against your Supabase instance.
2. Restore: pipe into your DanubeData managed Postgres with psql.
3. Storage: rclone sync from the Supabase Storage bucket (it is just S3) to your DanubeData bucket.
4. Auth: if you self-host GoTrue, you can keep the auth.users table as-is — password hashes, JWT signing secret, and all. If you switch to Authentik/Keycloak, users will need to reset passwords (or you import hashes via their import API if compatible).
5. RLS policies: they are standard Postgres — they move with the dump.
6. Edge Functions: Supabase's are Deno. Knative runs any container, so wrap the function in a small Deno Docker image and redeploy.
7. Realtime: point the @supabase/supabase-js client at your self-hosted realtime server, or switch to the LISTEN/NOTIFY pattern.

Typical migration timeline for a SaaS at 20k MAU: a weekend for the data move, one more weekend to port Edge Functions, a week of dual-writes before cutover. Total downtime: well under an hour with a proper cutover plan.

When Supabase Is Still the Right Answer

For balance — the composable approach is not universally better:

• If you are shipping an MVP in the next two weeks and have never set up PostgREST, Supabase's out-of-the-box DX saves real days.
• If your use case is a global B2C app and latency to Sydney matters more than data sovereignty, a US cloud may genuinely be the right trade-off.
• If your team has zero ops appetite and you do not want to touch Postgres roles, PostgREST config, or Authentik groups, Supabase packages all of that into a dashboard.

The argument for DanubeData's composable stack is strongest when at least one of these is true: you have EU customers in regulated industries (healthcare, legal, finance, public sector), you are past product-market fit and pricing matters, you want to avoid Schrems II paperwork, or you like Postgres and want direct access to it without a middle layer.

FAQ

Can I really migrate off Supabase without rewriting my app?

Mostly yes. If you stay on the PostgREST + GoTrue + S3 model, @supabase/supabase-js works against a self-hosted stack by just changing the URL and anon key. The parts that need code changes are Edge Functions (port the Deno handler to a Knative service) and any hardcoded Supabase management-API calls (rare in application code).

Does Row-Level Security work the same way?

RLS is a Postgres feature, not a Supabase feature — it moves with your database dump. The only wiring you need is a JWT-parsing helper function (like the auth.uid() above) so policies can read the caller's identity from the JWT your API gateway injects as request.jwt.claims.

What about realtime subscriptions — do they still work?

If you self-host the Supabase realtime Elixir server, supabase.channel() works unchanged. If you use the LISTEN/NOTIFY + SSE approach, you swap the client to an EventSource-based helper — about 30 lines of code. Most apps only use realtime for a couple of tables (presence, notifications), so the surface area is small.

Is the CLOUD Act really a problem if my data is in Frankfurt?

It depends on your threat model. For marketing sites and public data, probably not. For a legal-tech SaaS holding client attorney-client privilege documents, or a hospital app holding PHI/PII on EU patients, CLOUD Act exposure is a genuine compliance item that your DPO will flag. The safe answer: operate with an EU-only entity (like DanubeData, a Romanian company running in Germany) and you never have to litigate the question.

How does Supabase's pricing actually compare at scale?

Supabase Pro is $25/mo, but that is a starting point — you pay extra for compute (add-ons from $10 to $3,730/mo), storage beyond 100 GB ($0.021/GB), egress beyond 250 GB ($0.09/GB), and additional project branches. A production SaaS rarely runs under $200/mo and often crosses $500/mo. The DanubeData composable stack stays roughly flat — managed Postgres is €19.99 whether you have 10 users or 10,000.

Can I keep using @supabase/supabase-js in the frontend?

Yes, if you self-host PostgREST + GoTrue + Storage. The client library only cares about URL + JWT secret + API shape, all of which are standard. The one thing you lose is the Supabase Dashboard — which is fine because the DanubeData console plus pgAdmin/Beekeeper covers most admin tasks.

What about pgvector / AI features?

DanubeData's managed Postgres ships with pgvector enabled. The API is identical — create extension vector;, define a column as vector(1536), and run cosine-similarity queries. You can wire the same Supabase AI example code unchanged.

Do I get backups and point-in-time recovery?

Managed Postgres on DanubeData takes automated TopoLVM snapshots on a daily cadence and supports on-demand snapshots via the API. For PITR-grade recovery (any second in the last 7 days) you add WAL archiving to S3 — a 20-line postgresql.conf change that we enable on request. Object storage and VPS both have separate backup flows.

Getting Started

If you want to try the composable stack without committing, DanubeData gives new accounts €50 in credits — enough for roughly two months of the full Postgres + Storage + Serverless footprint described above.

1. Create a DanubeData account (takes about 60 seconds, no credit card for the free credit).
2. Create a managed PostgreSQL 17 instance in the Falkenstein region.
3. Spin up an Object Storage bucket — the S3-compatible endpoint is live immediately.
4. (Optional) Deploy a small VPS for PostgREST + Authentik, or stand up a Knative serverless container from your Git repo.
5. Import your Supabase dump, cut over your frontend, and enjoy a Schrems-II-clean backend at a fraction of the price.

The whole point of Supabase was that Postgres, Auth, Storage, and Functions do not have to be four separate services to feel integrated. With a modern European managed provider, you can have the same coherence — without the US legal surface and without paying $599/month for the privilege.

👉 Start building on DanubeData — or talk to our team if you want help with a migration plan.