The Data Sovereignty Problem
When a SaaS compliance tool connects to your database, it typically needs:
- Read access to your schema metadata
- Read access to table contents for PII scanning
- Sometimes write access for automated remediation
This means your data — or at least metadata about your data — now lives on someone else's infrastructure. For organizations bound by EU data sovereignty requirements, Schrems II implications, or German public sector regulations, this is often a dealbreaker.
In-Database Architecture
pgcomply takes a fundamentally different approach:
Traditional SaaS:
Your DB → External Scanner → SaaS Dashboard → Results
(Data leaves your infrastructure)
pgcomply:
Your DB → pgcomply.sql (runs inside DB) → Results stay in DB
(Nothing leaves your infrastructure)
The extension is a single SQL file that creates functions in a pgcomply schema. Every operation happens within PostgreSQL's existing security perimeter. The audit trail lives in your database. Reports are generated from your data.
Why This Matters for EU Organizations
GDPR Article 28: If a compliance tool processes your personal data, it becomes a data processor requiring a DPA (Data Processing Agreement).
Schrems II: Transferring personal data to US-based SaaS providers requires adequate safeguards. In-database tools eliminate this concern entirely.
German BSI Guidelines: German federal agencies require IT-Grundschutz compliance, which favors self-hosted solutions with auditable source code.
Zero Vendor Lock-In
pgcomply modifies nothing in your existing schema. It creates its own schema (pgcomply), its own tables, and its own functions. If you uninstall:
DROP SCHEMA pgcomply CASCADE;
Your database is exactly as it was before. No data migration, no export needed, no orphaned dependencies.
The Auditability Advantage
When your auditor asks "how does your compliance tool work internally?", closed-source tools require you to trust the vendor. With pgcomply:
-- Read any function's source code directly from PostgreSQL
SELECT prosrc FROM pg_proc
WHERE pronamespace = 'pgcomply'::regnamespace
AND proname = 'forget';
Every function is transparent. The auditor can verify that forget() actually deletes data, that verify_audit() actually checks the hash chain, and that health_check() actually tests what it claims.
License Comparison for Compliance Tools
| License | Implications | Examples | |---------|-------------|----------| | Proprietary SaaS | No source access, vendor dependency, data leaves infrastructure | Vanta, Drata, OneTrust | | AGPL | Must share modifications if providing network service | Some security tools | | MIT/BSD | Permissive, but no patent protection | Various small tools | | Apache 2.0 (pgcomply) | Permissive + patent protection, no copyleft | Full freedom to use, modify, distribute |
Apache 2.0 is specifically chosen because:
- No copyleft obligation: You don't have to open-source your application just because you use pgcomply
- Patent grant: Explicit protection against patent claims from the author
- Modification freedom: Fork it, modify it, keep modifications private
- Commercial use: Use it in commercial products without restriction
Risk Assessment: SaaS vs In-Database
For organizations conducting vendor risk assessments:
| Risk Category | SaaS Compliance Tool | pgcomply (In-Database) |
|--------------|---------------------|----------------------|
| Data exposure | Database metadata + potentially data sent externally | None — runs inside DB |
| Availability dependency | If vendor's SaaS is down, no compliance checks | Runs independently |
| Vendor lock-in | Data and workflows trapped in vendor platform | DROP SCHEMA to remove |
| Supply chain risk | Vendor's dependencies, infrastructure, employees | One SQL file, one dependency (pgcrypto) |
| Cost escalation | Annual contracts, per-seat pricing, feature gating | Free Community, fixed-price Pro |
| Regulatory changes | Dependent on vendor to implement | You control the code |
Summary
For organizations where data sovereignty matters, in-database compliance tools eliminate the risk of external data exposure. pgcomply runs where your data lives, requires no external connections, and is fully auditable as open-source software. This is not just a technical preference — it is a regulatory requirement for many EU organizations.