Most-deployed OSS relational database. Mature InnoDB storage engine, strong replication (statement + row + group), JSON column type with functional indexes. License: GPL-2.0 for the Community edition (OSI-approved); Commercial license available from Oracle for MySQL Enterprise. RBAC-based authorization without native row-level security; ABAC enforcement happens at the application or L5 governance layer.
MySQL is the most-deployed OSS relational database, with mature InnoDB storage, strong replication, and a JSON column type that handles semi-structured data without forcing a NoSQL detour. As an L1 system of record for agent stacks, it covers OLTP and read-heavy workloads well; PostgreSQL is the more capable peer for advanced governance (RLS), lineage (FDWs), and ecosystem extensions (pgvector, pgaudit). Pick MySQL when the team has existing operational expertise, when the deployment target is a managed MySQL service (RDS, Aurora, Cloud SQL, Azure Database for MySQL), or when application requirements fit InnoDB's performance profile cleanly.
MySQL's trust posture is solid for OLTP but the access-control model is RBAC-only — there's no native row-level security like Postgres RLS. ABAC enforcement and per-row policy decisions need to live at L5 (OPA, AWS Verified Permissions, Cerbos) or in application code, not at the database. Audit logging is reliable in MySQL Enterprise and via the McAfee plugin in Community, but it's an addition rather than a built-in. The compliance posture is deployment-dependent: the Community OSS distribution doesn't sign BAAs; managed deployments do.
Sub-millisecond p95 reads from buffer pool, indexed point lookups in microseconds, tens of thousands of TPS on commodity hardware. Cap rule N/A.
Standard SQL with MySQL extensions. Not natural language but a well-known query interface. Cap rule N/A.
GRANT-based RBAC with database/table/column-level permissions and dynamic privileges in MySQL 8. No native row-level security like Postgres RLS. Cap rule applied: RBAC-only without ABAC caps at 3.
Multi-platform, multi-cloud — every major cloud has managed MySQL (AWS RDS, Aurora, GCP Cloud SQL, Azure Database for MySQL). InnoDB Cluster and Group Replication for HA. Cap rule N/A.
JSON column type with functional indexes, generated columns, JSON_TABLE for SQL-over-JSON. No FDW equivalent. No native lineage. Cap rule N/A — close to C=3 cap but JSON support and information_schema lift it just over.
Performance Schema, slow query log, general query log, audit log via plugin. sum_timer_wait gives per-query cost attribution. Cap rule N/A.
G1=Y (RBAC with dynamic privileges, sub-10ms enforcement), G2=Y (audit log plugin when configured), G3=N, G4=Y (binary log + point-in-time recovery), G5=N, G6=Y (industry-standard, mappable). 4/6 -> 4.
O1=Y (Performance Schema + Datadog/New Relic/Prometheus mysql_exporter), O2=N, O3=Y (sum_timer_wait per-query cost), O4=Y (P_S + slow log alerting), O5=N, O6=N. 4/6 -> 4.
A1=Y (sub-ms p95 for indexed reads), A2=Y (statement + row-based replication), A3=N (no integral cache; query cache deprecated), A4=Y (Group Replication HA), A5=Y (sharding + read replicas), A6=Y (parallel query in 8.0.14+). 5/6 -> 4.
L1=N, L2=N, L3=N, L4=N, L5=Y (information_schema as terminology resource), L6=N. 1/6 -> 2 strict; lenient bump to 3 for sys schema metadata richness, parity-adjacent with peer DBs.
S1=Y (mature ACID InnoDB), S2=Y (NOT NULL constraints, defaults), S3=Y (replication consistency), S4=Y (strong typing), S5=Y (constraints + triggers as quality gates), S6=Y (Performance Schema flags anomalies). 6/6 -> 5.
Best suited for
Compliance certifications
MySQL Community (GPL-2.0) holds no compliance certifications at the project level. MySQL Enterprise (Oracle commercial) has compliance documentation but customers must operate it for attestation. Compliance for regulated workloads typically comes from managed deployments: AWS RDS for MySQL (HIPAA BAA, SOC 2, FedRAMP), Aurora MySQL (same plus Aurora-specific attestations), GCP Cloud SQL for MySQL (HIPAA BAA, SOC 2, FedRAMP Moderate), Azure Database for MySQL (HIPAA BAA, SOC 2).
Use with caution for
Choose Postgres for richer governance (native RLS), advanced extensions (pgvector for L4 vector search, pgaudit for compliance audit), FDW for cross-system queries, and stronger community-driven trajectory. MySQL wins on raw OLTP simplicity, broader operator pool, and JSON_TABLE syntax familiarity. For AI stacks specifically, Postgres is generally preferable because pgvector lets you collapse L1 RDBMS and L1 vector store into one engine.
View analysis →Choose Azure SQL Hyperscale for Azure-native deployments needing massive horizontal scale with managed compliance posture. MySQL wins on portability and OSS license; Azure SQL wins on integrated Azure tooling and per-service compliance attestations.
View analysis →Role: L1 OLTP relational substrate. Stores transactional and tenant data. Replication scales reads; group replication provides HA.
Upstream: Receives writes from application services and agent stacks. Configuration via my.cnf, Group Replication topology controls replication semantics.
Downstream: Serves reads to application services, L2 CDC pipelines (Debezium, AWS DMS), L3 transformation engines (dbt against replicas), L4 retrieval pipelines (RAG metadata lookups), L6 observability (Performance Schema scrape via mysql_exporter).
Mitigation: Use MySQL Enterprise audit log (commercial) or McAfee MySQL Audit Plugin (free) or upgrade to a managed service with audit on by default. Validate audit events appear after triggering test access.
Mitigation: Enforce policy at L5 (OPA, Verified Permissions, Cerbos) before the query reaches MySQL, or via views with WHERE clauses tied to session context. Don't rely solely on application-code filtering.
Mitigation: Use semi-synchronous or Group Replication for stricter durability. Document which queries are okay against replicas and which must hit the primary.
Mitigation: Use Percona XtraBackup or built-in Cloud SQL/RDS automated backups with binary log retention for point-in-time recovery. Test restore at least quarterly.
MySQL on Aurora handles the OLTP. Debezium streams CDC to a vector DB at L4 for retrieval. Audit log to SIEM. Application enforces ABAC on top.
Use AWS RDS for MySQL with HIPAA BAA, audit log enabled, encryption at rest. Application or L5 layer enforces ABAC since MySQL has no RLS. Postgres + pgaudit + RLS would be a stronger fit if greenfield.
Postgres + pgvector is the canonical choice here. MySQL has no equivalent native vector type.
This analysis is AI-generated using the INPACT and GOALS frameworks from "Trust Before Intelligence." Scores and assessments are algorithmic and may not reflect the vendor's complete capabilities. Always validate with your own evaluation.