Neon EU Alternative 2026: GDPR, CLOUD Act, and the Serverless Postgres Jurisdiction Problem

Post #677 in the sota.io EU Compliance Series

Neon has become one of the most popular serverless Postgres platforms for developers. Its branch-per-preview-environment feature maps directly onto modern Git workflows, making it the default database choice for teams deploying on Vercel. Neon offers scale-to-zero compute, autoscaling, point-in-time restore, and a generous free tier that has driven rapid developer adoption.

Neon has an EU region in Frankfurt. Its infrastructure runs on AWS eu-central-1. It offers a Data Processing Agreement.

The problem is the same one that affects Vercel, Supabase, Firebase, and Cloudflare: Neon Inc. is a US corporation headquartered in San Francisco, California. The CLOUD Act (18 U.S.C. § 2713) applies to it, regardless of which country stores your data. A valid US government order can compel Neon to produce Frankfurt-stored database contents, branches, snapshots, and connection logs.

There is a second issue specific to Neon's architecture that is worth examining in detail: Neon is the technology behind Vercel Postgres. Many developers using Vercel Postgres do not know they are running on Neon Inc.'s managed service. The CLOUD Act exposure is not just a Neon problem — it flows through to every developer who clicked "Enable Postgres" in their Vercel dashboard.

This post analyses Neon's GDPR and CLOUD Act exposure, maps each product feature to its legal risk, and provides a complete guide to EU-native serverless Postgres alternatives for 2026.

What Neon Actually Is

Neon is a serverless Postgres platform built on a novel storage architecture that separates compute from storage:

The key architectural insight is that Neon's storage layer is backed by object storage (AWS S3 on AWS-hosted regions) and that branches are implemented as copy-on-write references into this storage tree. Every branch, every snapshot, and every WAL segment lives in this S3-backed layer.

The Hidden Neon: Vercel Postgres

When Vercel launched Vercel Postgres in 2023, it was powered by Neon under the hood. Vercel Postgres is Neon — same infrastructure, same US entity ownership, same CLOUD Act exposure — packaged with a Vercel-branded interface.

The infrastructure chain for a developer using Vercel Postgres looks like this:

Your EU User
    ↓ (database query)
Vercel Postgres (EU region)
    ↓ (actually powered by)
Neon Inc. (San Francisco, CA, USA) — CLOUD Act subject
    ↓ (runs on)
AWS eu-central-1 (Frankfurt)
    ↓ (owned by)
Amazon.com Inc. (Seattle, WA, USA) — CLOUD Act subject

Three US entities in the chain. The developer who built their application thinking "Vercel Postgres stores data in Frankfurt, so we're GDPR-compliant" has unknowingly created a multi-layer CLOUD Act exposure — without ever visiting neon.tech.

This is not a minor footnote. The GDPR's accountability principle (Art. 5(2)) requires controllers to be able to demonstrate compliance. A controller who cannot identify their actual sub-processors (Neon, AWS) cannot demonstrate compliance. The DPA relationship that matters for CLOUD Act exposure is not just Vercel→developer; it is Neon→developer and AWS→Neon→developer.

The Jurisdiction Stack

For a developer using Neon directly (not via Vercel Postgres):

Your EU User
    ↓ (HTTPS/TCP)
Neon Proxy (EU Frankfurt)
    ↓ (runs on)
AWS eu-central-1 (Frankfurt)
    ↓ (managed by)
Neon Inc. (San Francisco, CA, USA) — CLOUD Act subject
    ↓ (storage layer)
AWS S3 eu-central-1 — owned by Amazon (Seattle, WA, USA) — CLOUD Act subject

Under CLOUD Act § 2713(a), US persons (including US corporations) must preserve and disclose the contents of wire or electronic communications stored anywhere in the world when compelled by valid US legal process. Neon Inc.'s Frankfurt nodes are US-controlled infrastructure.

The CJEU's Schrems II ruling (C-311/18, 2020) established that Standard Contractual Clauses do not override surveillance laws that undermine their effectiveness. The CLOUD Act was designed to do exactly that — override offshore storage arguments. A Neon DPA with SCCs does not protect Frankfurt data from a valid US government order directed at Neon Inc.

Neon Feature Risk Map

Neon's architecture creates CLOUD Act exposure across multiple surfaces, some of which are less obvious than others:

Database Branches

Neon's branching feature is its most distinctive capability. Every branch is a point-in-time copy-on-write snapshot of the storage tree.

CLOUD Act exposure: Each branch contains a full snapshot of your database at the branch point. A legal order compelling production of your production database also compels production of every branch derived from it. For a team with 50 preview environments (one per open PR), that is 50 separate snapshots of production data, all subject to compulsion.

GDPR implication: If your branches contain real user data (even anonymised for testing, if re-identification is possible), each branch is a separate personal data processing point requiring its own legal basis under GDPR Art. 6. Neon's DPA covers processing on your behalf — it does not address the legal basis for the data itself.

Scale-to-Zero Compute

When Neon compute scales to zero, the compute node is suspended, but the storage layer remains active. Cold data is stored as compressed WAL segments in AWS S3.

CLOUD Act exposure: "Zero-scale" does not mean zero-data. The WAL segments on S3 contain the full history of every write operation. A compulsion order does not require active compute — Neon can restore and export data from WAL segments without running your compute node.

GDPR implication: GDPR Art. 5(1)(e) (storage limitation) requires data to be kept no longer than necessary. Neon's WAL retention (typically 7-30 days) means deleted data may persist in WAL history under US jurisdiction long after it was deleted from your Postgres tables.

Connection Pooler and Proxy Logs

Neon's connection pooler (modified PgBouncer) and Neon Proxy log connection events, query fingerprints, and error conditions.

CLOUD Act exposure: Connection logs constitute metadata about your users' activity patterns. Even query fingerprints (without parameter values) can reveal behavioural data. These logs are retained by Neon on its US-controlled infrastructure.

GDPR implication: GDPR Art. 32 requires appropriate technical measures for processing security. Connection metadata that reveals user behaviour patterns is personal data if it can be linked to individuals — and Neon's logs include client IP addresses, which are personal data under GDPR (C-582/14, Breyer).

Point-in-Time Restore

Neon stores WAL history to enable point-in-time restore. This history is typically retained for 7 days on the free tier and up to 30 days on paid plans.

CLOUD Act exposure: Every version of your database within the retention window is accessible to Neon — and therefore compellable under US legal process. If a user requested erasure under GDPR Art. 17 and you deleted their record, that deletion may not propagate into WAL history within the retention window.

GDPR implication: The "right to be forgotten" under GDPR Art. 17 is technically difficult to implement when the storage layer retains WAL history. Neon's DPA does not address this gap explicitly. A data subject request to erase personal data from a Neon-hosted database may not erase it from the WAL history that Neon retains.

Neon Console and Dashboard

The Neon web console processes metadata about your database usage: project names, branch names, compute hours, query editor history.

CLOUD Act exposure: Project and branch names often contain identifiable information (e.g., "user-onboarding-fix", "client-acme-prod"). Query editor history may contain sensitive queries with parameter values. All of this is stored on Neon Inc.'s US-controlled infrastructure.

GDPR implication: Console metadata is personal data if it relates to identifiable persons (your team members). GDPR Art. 13 notices to your team should disclose Neon Inc. as a sub-processor if they use the Neon console.

GDPR DPA Analysis

Neon offers a Data Processing Agreement that covers:

The core gap: Neon's DPA frames the relationship correctly for normal GDPR processing scenarios. It does not — and cannot — address the fundamental issue that Neon Inc. is a US entity subject to US compulsion orders that the GDPR cannot override.

Python: Neon GDPR Compliance Analyser

from dataclasses import dataclass, field
from enum import Enum
from typing import Optional

class RiskLevel(Enum):
    CRITICAL = "CRITICAL"
    HIGH = "HIGH"
    MEDIUM = "MEDIUM"
    LOW = "LOW"

@dataclass
class NeonGDPRFinding:
    component: str
    risk: RiskLevel
    cloud_act_exposure: bool
    description: str
    gdpr_articles: list[str]
    mitigation: Optional[str] = None

class NeonGDPRAnalyser:
    def __init__(self):
        self.entity = "Neon Inc."
        self.jurisdiction = "San Francisco, CA, USA"
        self.infrastructure = "AWS eu-central-1 (Frankfurt) — owned by Amazon, Inc. (USA)"
        self.cloud_act_subject = True
        self.fisa_702_subject = True

    def analyse(self) -> list[NeonGDPRFinding]:
        return [
            NeonGDPRFinding(
                component="Neon Entity (US incorporation)",
                risk=RiskLevel.CRITICAL,
                cloud_act_exposure=True,
                description="Neon Inc. is a US corporation. CLOUD Act § 2713 applies "
                           "regardless of EU data centre location.",
                gdpr_articles=["Art. 44", "Art. 46", "Art. 49"],
                mitigation="Use EU-incorporated managed Postgres provider."
            ),
            NeonGDPRFinding(
                component="Vercel Postgres (hidden Neon)",
                risk=RiskLevel.CRITICAL,
                cloud_act_exposure=True,
                description="Vercel Postgres is powered by Neon Inc. — a US entity. "
                           "Controllers using Vercel Postgres must list Neon Inc. as "
                           "a sub-processor in their GDPR records.",
                gdpr_articles=["Art. 5(2)", "Art. 28(3)", "Art. 30"],
                mitigation="Identify and document sub-processor chain explicitly."
            ),
            NeonGDPRFinding(
                component="Database Branches",
                risk=RiskLevel.HIGH,
                cloud_act_exposure=True,
                description="Each branch is a point-in-time snapshot subject to "
                           "compulsion. 50 PR preview branches = 50 data exposure points.",
                gdpr_articles=["Art. 5(1)(b)", "Art. 6", "Art. 25"],
                mitigation="Do not use real user data in preview branches. Use "
                           "anonymised datasets for branch environments."
            ),
            NeonGDPRFinding(
                component="WAL History (Scale-to-Zero)",
                risk=RiskLevel.HIGH,
                cloud_act_exposure=True,
                description="WAL segments on AWS S3 retain full write history. "
                           "GDPR Art. 17 erasure may not propagate into WAL retention window.",
                gdpr_articles=["Art. 5(1)(e)", "Art. 17", "Art. 32"],
                mitigation="Implement application-level pseudonymisation before writing "
                           "to Postgres. Document WAL retention gap in DPA."
            ),
            NeonGDPRFinding(
                component="Connection Pooler Logs",
                risk=RiskLevel.HIGH,
                cloud_act_exposure=True,
                description="Connection logs include client IPs (personal data per C-582/14). "
                           "Retained on US-controlled infrastructure.",
                gdpr_articles=["Art. 4(1)", "Art. 5(1)(a)", "Art. 32"],
                mitigation="Use private networking where possible. Request log "
                           "retention minimisation in DPA negotiations."
            ),
            NeonGDPRFinding(
                component="Point-in-Time Restore (PITR)",
                risk=RiskLevel.HIGH,
                cloud_act_exposure=True,
                description="PITR history (7-30 days) retains all versions of "
                           "personal data including post-erasure versions.",
                gdpr_articles=["Art. 17", "Art. 25(1)"],
                mitigation="Document PITR retention in privacy notices. Implement "
                           "application-level deletion workflows that account for retention gap."
            ),
            NeonGDPRFinding(
                component="Neon Console Metadata",
                risk=RiskLevel.MEDIUM,
                cloud_act_exposure=True,
                description="Project/branch names, query editor history, and team "
                           "member data stored on US infrastructure.",
                gdpr_articles=["Art. 13", "Art. 28(3)(a)"],
                mitigation="List Neon Inc. in employee privacy notices. "
                           "Avoid personally identifiable names in project/branch metadata."
            ),
            NeonGDPRFinding(
                component="AWS Sub-Processor",
                risk=RiskLevel.MEDIUM,
                cloud_act_exposure=True,
                description="Neon's storage layer runs on AWS S3 eu-central-1 — "
                           "Amazon.com Inc. is a US entity and a secondary CLOUD Act subject.",
                gdpr_articles=["Art. 28(2)", "Art. 28(4)"],
                mitigation="Records of processing must include both Neon Inc. and "
                           "Amazon.com Inc. as sub-processors."
            ),
        ]

    def print_report(self):
        findings = self.analyse()
        print(f"Neon GDPR Compliance Report")
        print(f"Entity: {self.entity} ({self.jurisdiction})")
        print(f"Infrastructure: {self.infrastructure}")
        print(f"CLOUD Act subject: {self.cloud_act_subject}")
        print(f"FISA 702 subject: {self.fisa_702_subject}")
        print()
        for f in findings:
            print(f"[{f.risk.value}] {f.component}")
            print(f"  CLOUD Act: {'YES' if f.cloud_act_exposure else 'No'}")
            print(f"  {f.description}")
            print(f"  GDPR: {', '.join(f.gdpr_articles)}")
            if f.mitigation:
                print(f"  Mitigation: {f.mitigation}")
            print()

if __name__ == "__main__":
    NeonGDPRAnalyser().print_report()

EU-Native Serverless Postgres Alternatives

The core requirement: a PostgreSQL provider incorporated in the EU (or a country with adequate protection under GDPR Art. 45) that does not run on US-owned infrastructure at the parent entity level.

Note on Aiven: Aiven Group Oy is Finnish-incorporated (EU entity), but its managed databases run on AWS, Google Cloud, or Azure infrastructure — all US entities. This does not make Aiven subject to the CLOUD Act directly (Aiven is not a US company), but the underlying cloud providers are. The CLOUD Act exposure is at the infrastructure layer. Check Aiven's sub-processor list and infrastructure agreements before treating it as fully CLOUD-Act-free.

Note on Neon self-hosted: Neon open-sourced its core storage engine and compute layer in 2023. Running self-hosted Neon on a Hetzner or Scaleway VPS gives you the serverless Postgres experience (including branching) without Neon Inc.'s entity-level CLOUD Act exposure. This requires DevOps capacity but eliminates the jurisdiction problem entirely.

Migration Guide: Neon to EU-Native Postgres

Option 1: sota.io Managed PostgreSQL (Recommended — Zero DevOps)

sota.io is the EU-native Platform-as-a-Service. Your Postgres database runs on German-owned infrastructure with no US entity in the control chain.

# 1. Export from Neon
pg_dump "postgresql://user:pass@ep-xxx.eu-central-1.aws.neon.tech/dbname" \
  --no-owner --no-privileges \
  -f neon_export.sql

# 2. Create sota.io project and get connection string
# sota.io provides managed PostgreSQL with your project — no separate setup needed

# 3. Import to sota.io PostgreSQL
psql "postgresql://user:pass@postgres.sota.io/dbname" < neon_export.sql

# 4. Update environment variable in your application
# NEON_DATABASE_URL → DATABASE_URL (sota.io connection string)

Note on branching: sota.io does not offer native database branching (yet), but the most common use case — per-PR preview databases — can be replicated with a simple script:

#!/bin/bash
# Create a preview branch database for PR #$PR_NUMBER
PR_NUM=$1
DB_NAME="preview_pr_${PR_NUM}"

# Create database from template
psql $DATABASE_URL -c "CREATE DATABASE $DB_NAME TEMPLATE template0;"

# Restore latest dump into preview DB
pg_restore --no-owner -d "${DATABASE_URL_BASE}/${DB_NAME}" latest_dump.dump

echo "Preview DB ready: ${DATABASE_URL_BASE}/${DB_NAME}"

Option 2: Scaleway Serverless SQL (Serverless + EU-native)

Scaleway is a French company with no US parent. Scaleway Serverless SQL offers true serverless Postgres (scale to zero) on EU-native infrastructure.

# Export from Neon
pg_dump "$NEON_CONNECTION_STRING" -Fc -f backup.dump

# Create Scaleway Serverless SQL database via CLI
scw rdb instance create \
  --engine PostgreSQL-15 \
  --node-type SERVERLESS \
  --region fr-par \
  --name my-app-db

# Import
pg_restore --no-owner -d "$SCALEWAY_CONNECTION_STRING" backup.dump

Option 3: Self-Hosted Neon on Hetzner (Full Branching + EU control)

If you need Neon's branching feature specifically, running the open-source Neon stack on a Hetzner Cloud VPS gives you the same developer experience with EU-controlled infrastructure.

# On a Hetzner Cloud VPS (e.g., CPX21, Frankfurt region)
git clone https://github.com/neondatabase/neon.git
cd neon

# Build Neon (requires Rust, Docker)
make -j$(nproc)

# Run local Neon instance
./scripts/neon_local.py start

# Connection string (local)
postgresql://neondb_owner:password@localhost:55433/neondb

This is the most feature-complete EU alternative to managed Neon, but requires infrastructure management capability.

Application Code Changes

The Neon client library (@neondatabase/serverless) communicates over WebSocket to Neon's proxy. When migrating to standard Postgres, replace the Neon driver with a standard PostgreSQL client:

// Before (Neon serverless)
import { neon } from "@neondatabase/serverless";
const sql = neon(process.env.DATABASE_URL!);
const users = await sql`SELECT * FROM users WHERE id = ${userId}`;

// After (standard pg — works with sota.io, Scaleway, Hetzner)
import { Pool } from "pg";
const pool = new Pool({ connectionString: process.env.DATABASE_URL });
const { rows: users } = await pool.query(
  "SELECT * FROM users WHERE id = $1",
  [userId]
);

For Prisma or Drizzle ORM users, the migration is even simpler — just update the DATABASE_URL environment variable. The ORM abstracts the driver.

GDPR Checklist for Serverless Postgres in 2026

Use this checklist to evaluate any managed Postgres provider for GDPR compliance:

What the Neon DPA Cannot Cover

Neon's legal team has done what is possible within the constraints of US incorporation. Their DPA is well-structured. But there are fundamental limits:

1. CLOUD Act override: No DPA clause can override a valid US government compulsion order directed at Neon Inc. The GDPR's Art. 48 prohibition on unlawful transfers does not create an exemption from US statute in US courts.

2. FISA Section 702: Neon Inc. is a US electronic communications service provider. FISA Section 702 authorises surveillance of non-US persons' communications passing through US-controlled infrastructure. Your EU users' query data is in scope.

3. WAL history gap: The DPA does not address the gap between GDPR Art. 17 erasure rights and WAL history retention. This is a structural limitation of Neon's architecture, not a legal drafting oversight.

4. Branch data compulsion: The DPA frames processing as occurring per-database. It does not address the specific legal exposure created by branches — each of which is independently compellable.

Summary

Neon is an excellent serverless Postgres platform from a developer-experience perspective. Its branching model is genuinely innovative, and its scale-to-zero architecture reduces idle costs significantly.

But Neon Inc. is a US entity on US-owned (AWS) infrastructure. The CLOUD Act applies to everything it stores, regardless of which data centre holds the bytes. This includes your production database, every branch you create, every WAL segment in the retention window, and every connection log produced by the Neon proxy.

For EU developers building applications that process personal data of EU residents, this creates a structural GDPR compliance problem that no DPA can fully resolve.

The EU-native alternatives — sota.io for managed Postgres with zero DevOps, Scaleway Serverless SQL for true serverless EU infrastructure, or self-hosted Neon on Hetzner for full branching capability under EU control — address the jurisdiction problem at the entity level, not just the data-centre level.

See Also

• Vercel EU Alternative 2026: GDPR, CLOUD Act, and the Next.js Deployment Jurisdiction Problem — covers Vercel Postgres (Neon-powered) in the context of the full Vercel stack
• Supabase EU Alternative 2026: GDPR, CLOUD Act, and the BaaS Jurisdiction Problem — the Supabase managed Postgres analysis
• Firebase EU Alternative 2026: GDPR, CLOUD Act, and the BaaS Analytics-Präzedenz — Google Firebase compliance analysis
• Cloudflare Workers EU Alternative 2026: GDPR, CLOUD Act, and the Edge Computing Jurisdiction Problem — Cloudflare D1 (another US-controlled database)
• GCP EU Alternative 2026: GDPR, CLOUD Act, and the Google Cloud Jurisdiction Problem — Google Cloud Platform analysis