Why PostgreSQL Dominates in Regulated Industries

The Quiet Takeover

Ten years ago, asking a bank's DBA about PostgreSQL would get you a polite smile and a mention of Oracle. Today, PostgreSQL is the fastest-growing database in financial services, healthcare, and government. This is not an accident — it is a structural advantage.

Feature by Feature: What Regulators Care About

1. Row-Level Security

This is PostgreSQL's most underappreciated compliance feature. RLS allows the database itself to enforce data isolation:

ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;
CREATE POLICY patient_access ON patient_records
  USING (treating_physician = current_user);

Now a physician can only see their own patients' records, regardless of what query they run. The application does not need to enforce this — the database does.

Why this matters for compliance: regulators care about where access control is enforced. Application-level access control can be bypassed by a developer with database access. RLS cannot — it operates below the application layer.

Other databases: MySQL has no RLS. Oracle has Virtual Private Database (similar concept, proprietary syntax). SQL Server has RLS since 2016 but with more limited policy options.

2. ACID Transactions

Financial regulations require that transaction records are complete and consistent. If a bank transfer moves money from account A to account B, both the debit and credit must succeed or both must fail. This is not negotiable — it is a legal requirement under banking regulations.

PostgreSQL has been fully ACID-compliant since its inception. Every transaction is:

• Atomic: All changes succeed or all are rolled back
• Consistent: Database moves from one valid state to another
• Isolated: Concurrent transactions do not interfere
• Durable: Committed data survives system failures

This seems basic, but MySQL's default storage engine (InnoDB) only became fully ACID-compliant in version 5.5 (2010). Many legacy MySQL deployments still use configurations that sacrifice durability for performance.

3. Granular Audit Logging

The pg_audit extension provides statement-level and object-level audit logging:

AUDIT: SESSION,1,1,READ,SELECT,TABLE,public.users,SELECT * FROM users;

Every query, by every user, on every table — logged with timestamp, session ID, and full SQL statement. This satisfies:

• SOC 2 CC7.2 (system monitoring)
• DORA Article 12 (ICT logging)
• GDPR Article 5(2) (accountability)
• PCI DSS Requirement 10 (track access)

Combined with PostgreSQL's built-in logging (log_statement, log_connections, log_disconnections), you get a comprehensive access record without third-party tools.

4. Native Encryption

PostgreSQL supports:

• SSL/TLS for connection encryption (mandatory in any regulated environment)
• SCRAM-SHA-256 for password hashing (replacing the cryptographically broken MD5)
• pgcrypto extension for column-level encryption
• Transparent Data Encryption via filesystem-level encryption (LUKS, AWS KMS, etc.)

The gap: PostgreSQL does not have built-in Transparent Data Encryption (TDE) at the tablespace level like Oracle or SQL Server. This is addressed through filesystem encryption, which is the standard approach on cloud platforms (RDS, Cloud SQL, Azure all encrypt at rest by default).

5. Extensibility

PostgreSQL's extension system allows compliance tooling to run inside the database:

• pgcrypto — cryptographic functions
• pg_audit — granular audit logging
• pg_stat_statements — query performance monitoring
• Custom extensions — for organization-specific compliance requirements

This is fundamentally different from the MySQL/MariaDB approach, where compliance tooling must be external. In-database compliance means lower latency, stronger guarantees, and no data leaving the database boundary.

The Open Source Advantage for Compliance

Auditability

When a SOC 2 auditor asks "how does your encryption work?", PostgreSQL users can point to the source code. Oracle users point to documentation and trust the vendor. In a world of increasing supply-chain scrutiny, code transparency is a competitive advantage.

No Vendor Lock-In

Regulated organizations must have exit strategies. DORA Article 28 explicitly requires this for ICT third-party arrangements. With PostgreSQL:

• Data export: pg_dump produces standard SQL
• Provider migration: Same PostgreSQL runs on AWS, Azure, GCP, Hetzner, or bare metal
• No licensing: Apache 2.0 / PostgreSQL License — no per-core fees, no audit risk

Oracle customers face license audits, per-core pricing, and proprietary features that make migration expensive. For a regulated entity, this dependency is itself a risk that must be managed.

EU Data Sovereignty

The EU's push for digital sovereignty increasingly favors open-source technology. The German Sovereign Tech Fund, the French "cloud de confiance," and the EU Open Source Strategy all explicitly promote open-source databases. PostgreSQL is the only enterprise-grade relational database that qualifies.

This matters for public sector organizations that must host data within the EU on EU-controlled infrastructure. PostgreSQL runs anywhere — including EU-only cloud providers like OVHcloud, Hetzner, IONOS, and Scaleway.

Adoption Evidence

PostgreSQL's regulated-industry adoption is not theoretical:

• Financial services: Goldman Sachs migrated from proprietary databases. The UK's Financial Conduct Authority uses PostgreSQL.
• Healthcare: The US Department of Veterans Affairs runs PostgreSQL for patient records. European hospital information systems increasingly use PostgreSQL backends.
• Government: The UK Government Digital Service standardized on PostgreSQL. Germany's IT planning council recommends open-source databases.
• Telecommunications: Major EU telecoms use PostgreSQL for billing and customer data systems subject to GDPR.

What PostgreSQL Does Not Do

Honesty matters for credibility. PostgreSQL has limitations:

• No built-in TDE: Encryption at rest requires filesystem-level or cloud-provider encryption
• No native data masking: Requires extensions or view-based approaches
• No built-in compliance dashboards: You need to build or buy compliance reporting
• Connection overhead: Each connection consumes ~10MB RAM; high-connection applications need PgBouncer
• No automatic PII detection: Schema analysis requires external tooling or extensions

These gaps are addressable — through extensions, connection poolers, and compliance tools — but they are gaps nonetheless.

The Decision Framework

Choose PostgreSQL for regulated workloads when:

1. You need Row-Level Security for data isolation
2. Auditors require source code transparency
3. You want to avoid vendor lock-in (especially for DORA exit strategies)
4. EU data sovereignty requirements apply
5. Cost matters — PostgreSQL eliminates six- or seven-figure database licensing fees

Consider alternatives when:

1. You need built-in TDE without filesystem encryption (Oracle, SQL Server)
2. Your team has deep Oracle expertise and migration cost exceeds license cost
3. You need enterprise support with SLA guarantees (consider EDB, Crunchy Data, or managed cloud PostgreSQL)

For most regulated organizations starting new projects in 2026, PostgreSQL is the default choice. The feature set, community, and regulatory alignment make it the most defensible decision.