Sovereign Database Architecture: A Technical Guide

Data sovereignty is not just a legal requirement — it is an architectural decision. When your compliance data must reside in the EU under GDPR Articles 44-49^[1], you need a database architecture that guarantees residency at every layer: storage, processing, backup, and monitoring. This guide walks through a production-grade sovereign database stack built on PostgreSQL, pgvector, and EU-hosted infrastructure.

Architecture Principles

A sovereign database architecture must satisfy four constraints simultaneously. First, jurisdictional control: all data at rest and in transit must remain within EU legal jurisdiction, on infrastructure operated by EU-incorporated entities^[2]. Second, operational independence: no foreign entity can compel access to the data through their domestic legal process. Third, technical completeness: backups, replicas, logs, and monitoring data are all within scope — not just the primary database. Fourth, auditability: the architecture must produce evidence of compliance for regulators and auditors.

Why PostgreSQL

PostgreSQL is the foundation of sovereign database architecture for several reasons. It is open-source with a permissive license (PostgreSQL License)^[3], meaning no single vendor controls its development or can restrict its use. It supports enterprise features natively: row-level security (RLS), transparent data encryption, logical replication, and point-in-time recovery. And with the pgvector extension, it provides production-grade vector similarity search for AI/ML workloads without requiring a separate vector database.

For compliance workloads specifically, PostgreSQL's RLS capability is essential. You can enforce data access policies at the database level, ensuring that even if application code has a bug, the database itself prevents unauthorized data access. This is a defense-in-depth measure that auditors appreciate.

The Sovereign Stack

Our recommended sovereign stack consists of four layers:

Layer 1: Managed PostgreSQL. Supabase (EU region, europe-north1 in Helsinki) provides managed PostgreSQL with built-in authentication, real-time subscriptions, and automatic backups. Supabase is incorporated in the US, but when configured for EU regions, data resides on EU infrastructure. For maximum sovereignty, self-hosted PostgreSQL on Hetzner Helsinki or OVHcloud provides EU-incorporated infrastructure.

Layer 2: pgvector for AI workloads. The pgvector extension enables vector similarity search directly in PostgreSQL. This eliminates the need for a separate vector database (Pinecone, Weaviate) that may have US jurisdiction exposure. Store embeddings alongside relational data, query both with standard SQL, and keep everything in one sovereign database.

Layer 3: Encryption and key management. Use PostgreSQL's native encryption for data at rest. Manage encryption keys through EU-hosted key management — either self-managed (HashiCorp Vault on EU infrastructure) or Supabase Vault. Never store encryption keys on infrastructure with US jurisdiction exposure.

Layer 4: Backup and disaster recovery. Configure automated backups to EU-hosted object storage (Hetzner Storage Box, OVHcloud Object Storage, or Scaleway). Implement point-in-time recovery with WAL (Write-Ahead Log) archiving to EU storage. Test recovery procedures quarterly and document results for audit evidence.

Schema Design for Compliance Data

Compliance data has specific characteristics that influence schema design. It is append-heavy (audit logs, assessment records), rarely updated in place, requires temporal queries (state at a point in time), and must support regulatory retention periods (often 7-10 years)^[4].

We recommend a temporal schema pattern: every compliance record includes valid_from and valid_to timestamps, enabling point-in-time queries without losing historical state. Combined with PostgreSQL's table partitioning (partition by date range), this approach scales to millions of records while maintaining query performance and supporting retention policies.

Monitoring Without Jurisdiction Leakage

A commonly overlooked sovereignty gap is monitoring and observability. If your database runs in Helsinki but your monitoring data flows to Datadog (US) or New Relic (US), you have leaked metadata that reveals query patterns, performance characteristics, and potentially data values in error logs.

Use EU-hosted monitoring: Grafana Cloud (EU region), self-hosted Prometheus + Grafana on EU infrastructure, or Supabase's built-in monitoring. Ensure log aggregation (if used) also resides in EU jurisdiction. This is the detail that separates genuine sovereignty from checkbox compliance.

References

[1] Regulation (EU) 2016/679 (General Data Protection Regulation), Chapter V, Articles 44-49 on transfers of personal data to third countries. OJ L 119, 4.5.2016. EUR-Lex: 32016R0679.
[2] European Data Protection Board, “Recommendations 01/2020 on measures that supplement transfer tools to ensure compliance with the EU level of protection of personal data,” Version 2.0, adopted 18 June 2021.
[3] The PostgreSQL Global Development Group, “PostgreSQL License,” a liberal open source license similar to the BSD or MIT licenses. postgresql.org/about/licence/.
[4] Directive 2006/43/EC on statutory audits of annual accounts (as amended by Directive 2014/56/EU), Article 45 — retention of audit working papers for a minimum of five years; national implementations (e.g. Finland: Kirjanpitolaki 1336/1997 §10) require 6-10 years for accounting records.

DWS IQ uses this exact architecture: PostgreSQL + pgvector on Supabase EU, with Hetzner Helsinki for backup. See our platform at dws10.com.