Compare SQL Server data masking options — native Dynamic Data Masking (five mask types, SQL Server 2022 granular UNMASK) and Bytebase fleet-wide masking.

SQL Server Dynamic Data Masking

Compare Oracle data masking options — native Data Redaction (five function types via DBMS_REDACT, EXEMPT REDACTION POLICY) and Bytebase fleet-wide masking.

Oracle Dynamic Data Masking

You write a one-line UPDATE against production. Here's the lane that keeps it safe — the four phases, the controls, and what each one prevents.

How to Handle Ad-hoc Database Data Changes?

Notes on the MySQL 9.7 LTS release: Hypergraph Optimizer in Community, JSON Duality View DML, Group Replication observability, and Dynamic Data Masking for Enterprise.

Notes on the MySQL 9.7 LTS release

Most DAC implementations stop at the connection. Real DAC operates at the statement and covers three vectors: machine, human, and AI agent.

What is Database Access Control (DAC)?

Practical guide to dynamic data masking: five best practices, a vendor comparison, an end-to-end walkthrough, and the compliance specifics auditors ask about.

Dynamic Data Masking Best Practices

How Bytebase audits the workflow layer: every SQL, schema change, approval, and export tied to a real user identity, with structured exports for any SIEM.

How Bytebase Handles Audit Logging

PostgreSQL 19 features I'm excited about: planner advisor framework, DDL extraction, online REPACK, pg_stat_recovery, parallel autovacuum, sequence sync, and 64-bit MultiXact.

PostgreSQL 19 features I'm excited about

Bytebase is HIPAA-compliant — independent verification that our administrative, physical, and technical safeguards meet the HIPAA Security Rule for handling Protected Health Information.

HIPAA Compliance

PAM tools gate connections; databases also need SQL review, schema change workflow, and statement-level approval. Why most teams use PAM with Bytebase.

Bytebase vs. PAM: Why Database Teams Need More Than Privileged Access Management

What SOC 2 compliance audits actually want from your database audit log — not 'logging enabled' but evidence your auditor will accept. Lessons from going through our own audit.

SOC 2 Audit Log Requirements: Lessons From Our Own Audit

Bytebase vs. Atlas compared across migration approach, CI/CD, access control, and pricing. Updated for Atlas v1.1 and Bytebase 3.16.

Bytebase vs. Atlas: a side-by-side comparison for database schema migration

Audit-surviving database access control: statement-level enforcement across machine, human, and AI agent workloads, with the mistakes that fail SOC 2.

Database Access Control (DAC) Best Practices

SOX Section 404 requires IT general controls over database changes. Learn the ITGC domains, six audit questions teams fail, and how to build SOX-ready controls

Database Change Management for SOX Compliance

TRUNCATE and DELETE both remove rows, but they differ in speed, rollback behavior, and locking. Compare how they work in PostgreSQL, MySQL, and SQL Server.

TRUNCATE vs DELETE in SQL: Differences Across PostgreSQL, MySQL, and SQL Server

Six database design patterns for production systems: normalization, star schema, EAV, polymorphic associations, multi-tenancy, and anti-patterns.

Database Design Patterns Every Developer Should Know

pgvector adds vector storage and similarity search to PostgreSQL. Learn how to install it, query embeddings, build indexes, and decide when it is enough.

pgvector: How to Add Vector Search to PostgreSQL

Upsert inserts or updates a row based on key conflicts. Learn MySQL INSERT ON DUPLICATE KEY UPDATE, PostgreSQL ON CONFLICT, and SQL Server MERGE.

Upsert in SQL: INSERT ON DUPLICATE KEY vs ON CONFLICT Explained

AI agents need more than DDL. The full database lifecycle codified — schema, dependencies, ownership, history — gives LLMs the context to query correctly.

From Schema as Code to Schema as Context

Learn how to find and fix slow MySQL queries using the slow query log, EXPLAIN, index tuning, and query rewrites, with practical examples for each.

How to Fix Slow MySQL Queries: A Practical Guide

A detailed comparison of Convex and Supabase covering architecture, real-time capabilities, data model, pricing, and schema management to help you choose.

Convex vs Supabase: Which Backend Platform Should You Choose?

Blue-green deployments work cleanly for stateless apps. Databases are stateful. Learn what makes database blue-green deployments hard and how to do them safely.

Database Blue-Green Deployment: A Practical Guide

The 10 best data management tools in 2026 — database GUI clients, schema migration tools, data pipelines, and analytics platforms compared with pricing.

Top 10 Data Management Tools in 2026

How to give AI agents governed access to your databases. Identity, authorization, query control, audit, and masking — applied to a new principal type.

How to Govern AI Agent Database Access

Postgres-only SQL editors are designed specifically for Postgres databases, providing a more focused and efficient experience for Postgres users. In this post, we are taking a look at the top Postgres-only SQL editors in 2026.

Enterprise Text-to-SQL: Context, Evaluation, and Governance

Database deployment tools for devops teams in 2026.

Database Deployment Tools for DevOps Teams in 2026

Schema change detection and notification are essential for data pipelines. This article explains why a simple column rename can break your data pipeline and how to prevent it.

Schema Change Detection and Notification: Why a Simple Column Rename Can Break Your Data Pipeline

A comprehensive guide to understanding and analyzing Postgres query plans.

Postgres Query Plan: How to Read and Fix Performance Issues

This article explores the anatomy of Postgres permissions ERROR 42501.

The Anatomy of Postgres Permission ERROR 42501

Postgres Logs Explained: A Practical Guide for Production

Postgres 19 widens MultiXactOffset to 64 bits, eliminating the hidden 4 billion member limit that caused catastrophic outages for high-concurrency workloads.

Postgres 19 Feature Preview: 64-bit MultiXactOffset

A guide to MySQL schema migration best practice.

MySQL Schema Migration Best Practice

Postgres 19 introduces automatic sequence synchronization for logical replication, eliminating manual tracking and making major version upgrades and failover significantly easier.

Postgres 19 Feature Preview: Sequence Synchronization for Logical Replication

A guide to multi-environment deployments in databases.

Database Multi-Environment Deployments - The Challenges and Patterns

A guide to open source sensitive data discovery tools — from NLP libraries like spaCy and Microsoft Presidio to multi-source scanners like Hawk-Eye and full metadata platforms like OpenMetadata.

Top Open Source Sensitive Data Discovery Tools in 2026

Database audit logging has two layers: infrastructure (provider-managed) and workflow (database activity). What each captures, and why compliance requires both.

Database Audit Logging: Two Layers, One Trail

A practical guide to HITRUST database compliance covering access control, audit logging, change management, and data protection.

Database Compliance for HITRUST: Controls, Risks, and Best Practices

Learn why requiring a primary key is important and how the "Require Primary Key" review rule protects your production database.

Require Primary Key: A SQL Review Rule Explained

Learn why enforcing NOT VALID in CHECK constraints is important and how the "Enforce NOT VALID in CHECK" review rule protects your production database.

Enforce NOT VALID in CHECK: A SQL Review Rule Explained

Postgres Audit Logging Guide

Learn why CASCADE operations in SQL can lead to catastrophic data loss and how the "Prohibit CASCADE" review rule protects your production database.

Prohibit CASCADE: A SQL Review Rule Explained

A comprehensive guide on migrating from Supabase to AWS, covering database, auth, storage, functions, realtime, and networking.

How to Migrate from Supabase to AWS

Top open-source Postgres backup solutions for 2026.

What is Enterprise Database Management (EDM)?

What is Postgres Transaction ID (XID) Wraparound and how to monitor and prevent it.

Postgres Transaction ID (XID) Wraparound

How a CI/CD pipeline for database schema migration works end-to-end — what it gates, what it leaves outside, and the tools that fit.

How to Build a CI/CD Pipeline for Database Schema Migration

A practical guide to shipping features efficiently using PostgreSQL, covering development workflows, best practices, and real-world examples

How I Ship Features with Postgres

A comprehensive overview of the essential practices and principles necessary for achieving LGPD (Brazilian General Personal Data Protection Act), compliance within database operations, and its difference with GDPR

Database Compliance for LGPD: Implications and Best Practices

Explain what is Postgres LATERAL JOIN and how to use it.

What is Postgres LATERAL JOIN?

Introduction to MySQL Online DDL and its three algorithms: INSTANT, INPLACE, and COPY

MySQL Online DDL: A Practical Guide

List of open source postgres connection poolers

Open Source Postgres Connection Pooler

A comprehensive guide to understanding the dilemma of singular vs. plural table naming in SQL databases.

SQL Table Naming Dilemma: Singular vs. Plural

PostgreSQL 18 features that change how application developers write and ship code.

What's New in PostgreSQL 18: A Developer's Perspective

Compare Snowflake Dynamic Data Masking with database views and Bytebase fleet-wide masking — edition gate, policy management, audit trail.

Snowflake Dynamic Data Masking (DDM) and Alternatives

Top open-source Postgres authentication solutions for 2025.

Postgres Case Sensitivity Explained

A comprehensive guide to understanding pg_database_owner in Postgres

What is pg_database_owner in Postgres

Which operation causes a Postgres table rewrite

Which Postgres Operation causes a table rewrite

An engineering perspective to evaluate Postgres row-level-security footguns

Postgres Row-Level Security Footguns

An engineering perspective to evaluate Postgres rollback strategies

Postgres Rollback Explained

Learn how Postgres locks affect schema migrations and which DDL operations conflict with DML to achieve zero-downtime deployments.

Postgres Schema Migration without Downtime

A checklist of gh-ost limitations and potential gotchas

gh-ost Limitations You Need to Know Before Production

5 quick wins for application developers to improve Postgres reliability and make both their own and DBA/infrastructure teams' lives easier.

5 Postgres Production Tips for Application Developers

Learn how to use CREATE INDEX CONCURRENTLY in Postgres to build indexes without blocking writes. Pitfalls, safety checks, and performance tips.

How to Use Postgres CREATE INDEX CONCURRENTLY

An extensive comparison between Supabase and MongoDB on performance, usability, operability, ecosystem and more.

Supabase vs. MongoDB: a Complete Comparison in 2025

When evaluating database management tools, DataGrip and Bytebase represent two different philosophies: individual developer productivity versus team collaboration and governance.

Bytebase vs. DataGrip: a side-by-side comparison for database management

Supabase pricing starts free. We break down real costs for Pro ($25/mo) and Team ($599/mo) plans, explain overages, and compare each service head-to-head with AWS.

Supabase vs AWS: Feature and Pricing Comparison (2026)

Is Supabase free? Compare Supabase pricing vs AWS RDS and Aurora across free tier, Pro, and production plans. Includes Supabase free tier limits, storage costs, and compute pricing for 2026.

Supabase Pricing vs AWS RDS: Is Supabase Free? Full Cost Comparison (2026)

Learn how Bytebase enables organizations to implement comprehensive Database Security Lifecycle Management, unifying security and operations from development to production.

Database Security Lifecycle Management

Areas where MySQL shines and Postgres falls short.

Features I Wish Postgres Had but MySQL Already Has

Areas where PostgreSQL shines and MySQL falls short.

Features I Wish MySQL Had but Postgres Already Has

This guide focuses on HIPAA compliance at the database layer, providing healthcare organizations and database teams with practical guidance for implementing HIPAA Security Rule requirements.

HIPAA Data Security and Retention Requirements

Compare the online index creation difference between Postgres and MySQL

Postgres vs. MySQL: Online Index Creation

SOC 2 Data Security and Retention Requirements for Database Systems and How Bytebase Helps

SOC 2 Data Security and Retention Requirements

Compare the different indexing options between Postgres and MySQL

Postgres vs. MySQL: Indexing Options

Compare the JSON support difference between Postgres and MySQL

Postgres vs. MySQL: JSON Support

While PostgreSQL RLS is a powerful feature, it has inherent design limitations that hinder broader adoption. In this post, we’ll examine these limitations and explore alternatives.

Postgres Row-Level Security (RLS) Limitations and Alternatives

Evaluate several database schema diagram tools, and help you to choose the right one for 2025

Top 4 Free, Open Source Database Schema Diagram Tools to Visualize Database Easier in 2025

An overview of the most popular text-to-SQL AI tools in 2026, including DataGrip, TablePlus, SQL Chat, Vanna.ai, SQLAI.ai, Postgres.new, and DBHub MCP server. Compare features and capabilities to find the best SQL AI assistant for your workflow.

Top 5 Text-to-SQL Query Tools in 2026

Compare the DDL transaction difference between Postgres and MySQL

Postgres vs. MySQL: DDL Transaction Difference

Evaluate several TypeScript ORMs, and help you to choose the right one for 2025

Top TypeScript ORM 2025

Evaluate Prisma and TypeORM, and help you to choose the right TypeScript ORM for 2025

Prisma vs TypeORM: The Better TypeScript ORM in 2025

PostgreSQL 18 features and what they change for running production databases.

What's New in PostgreSQL 18: A DBA's Perspective

Explore alternatives to Amazon RDS, including 

RDS Alternatives in 2025

An extensive comparison between DynamoDB and Cassandra on performance, usability, operability, ecosystem and more.

DynamoDB vs. Cassandra: a Complete Comparison in 2025

An extensive comparison between DynamoDB and MongoDB on performance, usability, operability, ecosystem and more.

RDS vs. DynamoDB: a Complete Comparison in 2025

How gh-ost and pt-online-schema-change compare on architecture, cut-over, foreign keys, and runtime control — for teams choosing a MySQL online schema migration tool.

gh-ost vs pt-online-schema-change

GitHub and Bitbucket are both tools for code collaboration. This article compares the features and pricing of GitHub and Bitbucket.

GitHub vs Bitbucket:a Complete Comparison in 2025

Drizzle ORM vs Prisma comparison: type safety, performance, bundle size, serverless support, migrations, and ecosystem. Find out which TypeScript ORM is right for your project in 2026.

Drizzle ORM vs Prisma: Which TypeScript ORM Should You Use in 2026?

An engineering perspective to evaluate Google AlloyDB and Cloud SQL, and help you to choose the right Google Cloud database for 2025

AlloyDB vs. Cloud SQL: engineering guide to choose the right Google Cloud database for 2025

Understanding DynamoDB Pricing (2025)

A simple comparison of AWS Aurora versus RDS pricing in 2025, helping you understand key differences and choose the right database service for your needs and budget.

AWS Aurora vs. RDS Pricing: A Detailed Comparison 2025

Infrastructure as Code security tools help organizations identify vulnerabilities and misconfigurations in their infrastructure definitions. This post explores the top open-source IaC security tools available in 2025.

Top Open Source Infrastructure as Code (IaC) Security Tools in 2025

Compare the price of the mainstream managed PostgreSQL hosting providers

PostgreSQL Hosting Options in 2025: Pricing Comparison

Complete guide to AWS Aurora pricing: instance types and costs, Aurora Serverless v2 pricing, I/O-Optimized vs Standard, reserved instance savings, and real-world cost examples. Learn how to optimize your Aurora costs.

AWS Aurora Pricing Explained: Instance Types, Serverless, and Cost Optimization (2026)

Database governance tools help organizations manage database changes, enforce policies, and maintain data quality. This post explores the top open-source database governance tools available in 2025.

Top Open Source Database Governance Tools in 2025

Workflow orchestration tools help coordinate tasks, handle errors, and monitor execution processes. In this post, we are taking a look at open source workflow orchestration options

Top Open Source Workflow Orchestration Tools in 2025

Understanding AWS RDS Pricing (2025)

Compare the price of the mainstream managed MySQL hosting providers

MySQL Hosting Options in 2025: Pricing Comparison


[MySQL 9.7](https://dev.mysql.com/doc/relnotes/mysql/9.7/en/news-9-7-0.html) shipped on April 21, 2026. It's the first LTS since 8.4, and the first release after Oracle's February pledge to re-engage with the MySQL community. The [release announcement](https://blogs.oracle.com/mysql/mysql-9-7-0-lts-is-now-available-expanded-community-capabilities-and-dynamic-data-masking-for-enterprise) covers everything that landed; below are the ones that caught my attention after going through the release notes.

## The Hypergraph Optimizer

MySQL's classical optimizer is a left-deep, greedy join enumerator. It plans fast and produces good plans on OLTP. The plan shapes it can produce are limited: every join extends a single left-deep chain, hash-vs-nested-loop is not a general cost-based choice, and interesting orders are not part of the search. On analytic queries with many joins, that gap shows up as orders-of-magnitude differences in execution time.

The Hypergraph Optimizer is the rewrite. It implements DPhyp from Moerkotte and Neumann's [_Dynamic Programming Strikes Back_](https://15721.courses.cs.cmu.edu/spring2020/papers/20-optimizer2/p539-moerkotte.pdf) (SIGMOD 2008): a cost-based, hypergraph-aware enumerator that considers bushy plans, picks hash vs nested-loop per join based on cost, and propagates interesting orders. It first surfaced as a developer preview in 8.0.23 and spent the 9.x Innovation cycle behind Enterprise. 9.7 is where it crosses into Community.

```sql
-- Session-level
SET optimizer_switch = 'hypergraph_optimizer=on';

-- Statement-level
SELECT /*+ SET_VAR(optimizer_switch = 'hypergraph_optimizer=on') */
  o.id, c.name, SUM(li.price)
FROM orders o
JOIN customers c ON c.id = o.customer_id
JOIN line_items li ON li.order_id = o.id
WHERE o.created_at >= '2026-01-01'
GROUP BY o.id, c.name;
```

**Why it's useful:** A real planner for deep joins, star schemas, and analytical filters — without paying for Enterprise or moving to HeatWave. Per-statement opt-in via `SET_VAR` is the pragmatic pattern. Flipping it on globally is the wrong choice: the classical optimizer still wins on the OLTP fast path, and planning cost on simple queries is higher.

It is still experimental and off by default. On Oracle's published TPC-DS run, nearly half the queries improved by at least 25%, 19 improved by at least 50% — but 14 regressed by 50% or more. The wins outnumber the losses, but the losses are real. Refresh `ANALYZE TABLE` and your column histograms before flipping the switch; the hypergraph planner is far more sensitive to statistics quality than the classical one. And keep `SET_VAR` ready in both directions, in case a specific query is one of the losers.

## JSON Duality Views

JSON Duality Views let an application read and write a JSON document while the server stores the data as normalized relational rows. The 9.x Innovation track shipped them read-only in Community, read-write in Enterprise. 9.7 closes the gap: `INSERT`, `UPDATE`, and `DELETE` against a duality view are now supported in Community Server, with auto-increment propagation.

```sql
CREATE JSON DUALITY VIEW customer_orders AS
SELECT JSON_DUALITY_OBJECT{
  '_id': c.id,
  'name': c.name,
  'orders': [ SELECT JSON_DUALITY_OBJECT{
                '_id': o.id,
                'total': o.total_cents,
                'placed_at': o.created_at
              } FROM orders o WHERE o.customer_id = c.id ]
} FROM customers c;

-- Document-style write — server decomposes it into INSERT/UPDATE on base tables
INSERT INTO customer_orders VALUES (JSON_OBJECT(
  'name', 'Alice',
  'orders', JSON_ARRAY(JSON_OBJECT('total', 4200, 'placed_at', NOW()))
));
```

**Why it's useful:** Document and relational access from the same schema. A service that prefers documents reads and writes the view; an analytics pipeline reads the base tables directly. No ORM in the middle. Constraint violations on the base tables roll back the document write, which is the point — you want those errors loud, not papered over.

## Group Replication

Group Replication is already MySQL's clearest lead over Postgres: a multi-primary-capable, in-server HA topology with automatic failover, where Postgres still hands failover orchestration off to external tools. The catch was that running it well required Enterprise — the components that told you _why_ the group made a given decision lived only there. 9.7 closes that gap, which is what turns the lead from a paywalled one into a real one.

- **Replication Applier Metrics** — per-worker lag and throughput in multi-threaded replication.
- **Group Replication Flow Control Statistics** — how often, how long, and against which member flow control engaged.
- **Group Replication Resource Manager** — automatic eviction and rejoin of unhealthy members.
- **Group Replication Primary Election** — favors the most up-to-date eligible node during failover, not the lowest-UUID default.

**Why it's useful:** Your HA topology no longer has to track your support contract. Turn on applier metrics first — they're how you tell a hot worker apart from broader replication pressure. Resource manager and primary election actually change failover behavior, so roll those out against a staging cluster before production.

## OpenTelemetry Support

The Telemetry Component lands in Community. Previously Enterprise-only, it exports MySQL logs, metrics, and traces over OTLP. Configuration is component-based — installed and tuned like any other server component, not a separate plugin.

**Why it's useful:** MySQL is now on the same OTLP pipeline as everything else, which means MySQL spans land in the same dashboard as the application traces they're attached to. There's no longer a MySQL-shaped hole in centralized monitoring that needs a custom exporter to fill. One thing to plan for on busy clusters: the collector and the network path between it and the server have to handle the extra OTLP traffic.

## Dynamic Data Masking

Until 9.7, masking a sensitive column in MySQL meant one of three things: wrap the base table in a view, call an Enterprise masking function in every query that touched the column, or put a third-party gateway in front of the database. None of these survived a `SELECT *`, and none of them survived a developer pointing their own client at the read replica.

MySQL Enterprise 9.7 makes Dynamic Data Masking (DDM) a first-class object in the server. A masking policy decides, per row at query time, whether to return the original value or a transformed one, based on the executing user or active role. You attach the policy to a column on the base table, and every read path — `SELECT *`, `mysqldump`, ad-hoc client sessions — goes through it.

```sql
-- 1. Define a policy. The body is a CASE expression that returns either
--    the column value or a masked transformation of it.
CREATE MASKING POLICY mask_ssn AS (val VARCHAR(11))
RETURNS VARCHAR(11) ->
  CASE
    WHEN CURRENT_ROLE() IN ('compliance_auditor', 'pii_reader')
      THEN val
    ELSE mask_inner(val, 0, 4, 'X')
  END;

-- 2. Attach the policy to a column on the base table.
ALTER TABLE customers
  ALTER COLUMN ssn SET MASKING POLICY mask_ssn;

-- 3. Reads are filtered by the policy, transparently.
SELECT id, name, ssn FROM customers WHERE id = 42;
-- → 42 | Alice | XXXXX6789       (analyst role)
-- → 42 | Alice | 123-45-6789     (compliance_auditor role)
```

The policy body draws on Enterprise's pre-built masking library, which has shipped since 8.0 — `mask_inner`, `mask_outer`, `mask_pan`, `mask_ssn`, `gen_rnd_email`, `gen_rnd_us_phone`. The functions aren't new. What's new in 9.7 is the policy _object_: before, you could call these functions, but binding one to a column meant application code or a view. Now the server does that binding for you. The SQL surface looks a lot like [Snowflake's column-level DDM](https://docs.snowflake.com/en/user-guide/security-column-ddm-use) — same `CREATE MASKING POLICY ... RETURNS ... ->` shape, same `ALTER COLUMN ... SET MASKING POLICY` attachment — and not at all like Oracle's procedural `DBMS_REDACT.ADD_POLICY` API, which is the older sibling in the same family of products.

**Why it's useful:** Masking shifts from "every read path has to remember to call the function" to "the column is masked." A masked column is masked everywhere it appears, including inside `WHERE` and `JOIN` predicates, so the obvious side-channel — `WHERE ssn LIKE '123-%'` — is closed. One thing DDM doesn't do: it controls which roles see which columns in cleartext, but it doesn't control which rows a role can read at all. If both axes matter, pair it with row-level filtering.

## Re-earning the Trust

MySQL's community story drifted last year. Three-month stretches with no public commits. Layoffs inside the engineering team. On Hacker News, in conference hallways, in architecture reviews, the default answer became "use Postgres." Picking MySQL needed a defense.

That's changing. Oracle's February [New Era of MySQL Community Engagement](https://blogs.oracle.com/mysql/new-era-of-mysql-community-engagement) post made the promise; 9.7 keeps it. The optimizer rewrite ships in Community. Group Replication observability ships in Community. Dynamic Data Masking stays Enterprise — the right call, since the people buying masking are the same people buying the audit posture and support contract that come with it.

On operational merits, MySQL stands up against Postgres better than the consensus suggests:

- **Storage engine.** InnoDB is clustered-index and undo-log-based — old row versions live in the undo log, not the heap. Postgres's heap-plus-vacuum design is the [most-cited architectural pain point operators raise about Postgres](https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html). InnoDB tends to outperform heap+vacuum on OLTP workloads.
- **Replication and HA.** Group Replication ships in the server with automatic primary election and node eviction; MySQL Router and MySQL Shell finish the stack. Postgres has streaming replication in core but leaves failover orchestration to external tools.
- **Learning curve.** A new engineer is productive with MySQL in a day. Postgres asks more up front — roles, schemas, `search_path`, vacuum, autovacuum, TOAST, wraparound — and the first day is steeper.

## Further Reading

- [MySQL 9.7.0 release notes](https://dev.mysql.com/doc/relnotes/mysql/9.7/en/news-9-7-0.html)
- [Oracle: MySQL 9.7.0 LTS is now available](https://blogs.oracle.com/mysql/mysql-9-7-0-lts-is-now-available-expanded-community-capabilities-and-dynamic-data-masking-for-enterprise)
- [Oracle: The Hypergraph Optimizer is now available in MySQL 9.7 Community Edition](https://blogs.oracle.com/mysql/the-hypergraph-optimizer-is-now-available-in-mysql-9-7-community-edition)
- [Oracle: New Era of MySQL Community Engagement](https://blogs.oracle.com/mysql/new-era-of-mysql-community-engagement)



<HintBlock type="info">

This post is based on the [PostgreSQL 19 release notes draft](https://www.postgresql.org/docs/devel/release-19.html). The feature set firms up at beta freeze; we will update this post as PG 19 progresses through beta and RC.

</HintBlock>

| Update History | Comment          |
| -------------- | ---------------- |
| 2026/04/30     | Initial version. |

PostgreSQL 18 shipped asynchronous I/O as raw capability. PostgreSQL 19 is the operational counterpart, and the items below are the ones I'm most excited about. In-core plan advice closes the longest-running gap in the planner. DDL extraction lands in core. `REPACK` and checksums move out of the maintenance window. Lock contention and standby recovery state get first-class system views. The 32-bit MultiXact ceiling that has caused production outages is gone. Autovacuum becomes parallel and observable.

## pg_plan_advice

PostgreSQL's planner is excellent at the average case and occasionally wrong at the long tail. Skewed distributions, stale statistics, and many-table joins can push it onto an operationally unacceptable plan. The workarounds lived outside core: [pg_hint_plan extension](https://github.com/ossc-db/pg_hint_plan), application-level `SET enable_*` flags, third-party plan-locking extensions — each with its own semantics and lifecycle.

In February 2026, [Clerk traced an outage](https://clerk.com/blog/2026-02-19-system-outage-postmortem) to exactly this pattern: a column whose values were 99.9996% NULL, an `ANALYZE` whose sample happened to contain only NULLs, and a planner that concluded the column was 100% NULL. The plan that followed assumed zero non-null rows where there were over 17,000.

PostgreSQL 19 brings the answer inside core, in two layers.

**`pg_plan_advice`** introduces a planner-advisor framework. It generates a plan-advice string that captures the relevant plan choice — join order, scan method, etc. — and exposes a hook for other modules to inject advice at planning time. The advice can be passed inline via `EXPLAIN (PLAN_ADVICE '...')` for one-shot use.

**`pg_stash_advice`** persists plan-advice strings keyed by `(stash_name, queryId)` in dynamic shared memory and injects them automatically at planning time via the `pg_plan_advice` hook. One write. Effective across all sessions.

```sql
-- 1. Load the extension (must already be in shared_preload_libraries)
CREATE EXTENSION pg_stash_advice;

-- 2. Create a stash
SELECT pg_create_advice_stash('events_stash');

-- 3. Find the queryId
EXPLAIN (VERBOSE) SELECT * FROM events WHERE tenant_id = 42;
-- → Query Identifier: 9876543210

-- 4. Stash the advice for that queryId
SELECT pg_set_stashed_advice('events_stash', 9876543210,
    'INDEX_SCAN(events events_tenant_idx)');

-- 5. Activate the stash in this session
SET pg_stash_advice.stash_name = 'events_stash';

-- 6. Verify — the planner now picks the indexed path
EXPLAIN (COSTS OFF) SELECT count(*) FROM events WHERE tenant_id = 42;
-- → Index Scan using events_tenant_idx
```

Scope is controlled by the `pg_stash_advice.stash_name` GUC — `ALTER DATABASE`, `ALTER ROLE`, or session-level `SET`.

**Why it's useful:** Plan stability without application changes. One write to a stash takes effect across every session that runs the matching `queryId`, with no `pg_hint_plan` or third-party tooling. The right use case is a small set of queries with known planner regressions on production data. Applying advice has a cost even when it does not change the plan, so this is not a pattern to apply broadly across a workload.

## DDL extraction function

PostgreSQL has never shipped a way to pull the `CREATE` statement for a database, role, or tablespace out of the catalog. The data is there. The DDL is not. Every team that needs it writes its own extractor: a shell loop around `pg_dump --schema-only`, a hand-rolled catalog query inside a migration tool, a schema-management platform like Bytebase that reads the catalog directly and assembles the DDL. The implementations differ. The maintenance burden does not — every major Postgres release brings new catalog columns and new attribute encodings to absorb.

PostgreSQL 19 replaces those bespoke layers with a stable, in-core function-call contract. Three functions, one option shape, returning the DDL as text:

```sql
SELECT pg_get_database_ddl('mydb'::regdatabase);
SELECT pg_get_role_ddl('myrole'::regrole);
SELECT pg_get_tablespace_ddl('mytbs');
```

All three accept `pretty := true`. `pg_get_database_ddl()` additionally accepts `owner := false` and `tablespace := false` to suppress those clauses when the target environment differs.

**Why it's useful:** A stable, in-core contract replaces every team's bespoke extractor. Migration prep, CI/CD schema diffs, audit snapshots of role grants and database properties, embedded calls from schema-management tools — all stop parsing `pg_dump` output.

These functions complement `pg_dump` rather than replace it: single-object only, no dependency ordering, no indexes, triggers, or constraints. Permissions are scoped: `CONNECT` on the database, `USAGE` on the tablespace, superuser or self for roles.

## Online maintenance

Two long-standing maintenance pain points shrink. Both used to need a window.

**`REPACK` and `REPACK CONCURRENTLY`.** A single in-core command consolidates `VACUUM FULL`, `CLUSTER`, and the third-party `pg_repack` extension. With `CONCURRENTLY`, the rebuild runs without an `ACCESS EXCLUSIVE` lock — concurrent reads and writes proceed against the original heap while the new one is built and switched. `max_repack_replication_slots` controls the slot pool that backs the concurrent variant.

```sql
REPACK TABLE my_table;
REPACK TABLE my_table CONCURRENTLY;
REPACK INDEX my_index CONCURRENTLY;
```

**Online data checksum enable/disable.** Toggling checksums no longer requires stopping the cluster and running `pg_checksums` against a halted data directory. The change applies progressively in the running cluster.

**Why it's useful:** Both items remove a class of "schedule a window, hope nothing breaks" operations.

`REPACK CONCURRENTLY` deserves the same caution as any logical-decoding-backed feature: it consumes a replication slot, so a slow consumer or stuck transaction will hold WAL. Pin `max_repack_replication_slots` to a reasonable upper bound and monitor slot lag during long repacks. Online checksum toggling is the safer of the two — failure mode is a clean abort, not a locked-out cluster.

## Observability

Two diagnostic gaps close in 19. Lock history and standby recovery state get first-class system views.

### Locks

`pg_stat_lock` exposes per-lock-type statistics: counts and waits broken out by lock mode. `pg_locks` shows the snapshot. `pg_stat_lock` shows the history.

`log_lock_waits` is on by default. Long lock waits are now logged out of the box. Threshold and noise floor are unchanged — operators no longer need to flip the GUC in every new install.

**Why it's useful:** The combination matters more than either piece alone. `pg_locks` answers "who is blocked right now." `pg_stat_lock` answers "where is contention concentrated over time." The first informs immediate intervention. The second informs schema and indexing decisions. Build a dashboard query against `pg_stat_lock` filtered by relation and mode — most contention surprises sit in two or three hot tables.

### Recovery

Standby monitoring meant calling functions in sequence — `pg_last_wal_replay_lsn()`, `pg_last_wal_receive_lsn()`, `pg_get_wal_replay_pause_state()`, `pg_last_xact_replay_timestamp()` — and reconciling the results. Each call was its own snapshot. The answer to "where is this standby right now?" was a composite, not a reading.

PostgreSQL 19 adds `pg_stat_recovery`, a single system view that snapshots all of it from shared memory in one read. Fields cover:

- Last replayed WAL position and timeline
- End position and timeline of the WAL record currently being replayed
- Current WAL chunk start time
- Promotion trigger state
- Last commit/abort timestamp — the freshness signal for replication lag
- Recovery pause state

```sql
SELECT * FROM pg_stat_recovery;
```

The view returns no rows on a primary. Read access requires the `pg_read_all_stats` role.

**Why it's useful:** The atomic snapshot is the part that matters. Previously, when alerts fired on "replica too far behind," distinguishing real lag from a query that raced with a state transition meant correlating timestamps across multiple function calls. One view collapses that into a coherent reading for dashboards and runbooks. The current-WAL-chunk-start-time field has no prior function equivalent — it diagnoses standbys stuck mid-record rather than between records.

## Logical replication: sequence sync

Logical replication has reproduced table data faithfully since 10. It has not reproduced the sequences backing `SERIAL` and `IDENTITY` columns. Promote a subscriber to primary and the next `INSERT` triggers a primary-key violation against rows the application thought it owned.

PostgreSQL 19 closes the gap. Publications gain sequence support, a new `REFRESH SEQUENCES` subcommand triggers the copy, and a `sequencesync` worker batches the work.

```sql
CREATE PUBLICATION upgrade_pub FOR ALL TABLES, ALL SEQUENCES;

ALTER SUBSCRIPTION upgrade_sub REFRESH SEQUENCES;
```

`pg_subscription_rel.srsubstate` exposes per-sequence progress (`i` = INIT, `r` = READY).

**Why it's useful:** Zero-downtime upgrades and failover get safer. The behavioral catch is that sequences sync only when `REFRESH SEQUENCES` runs — they do not track continuously. Build the call into cutover runbooks, immediately before promoting the subscriber. For the deeper walkthrough including `pg_subscription_rel` query patterns, see [Postgres 19 Feature Preview: Sequence Synchronization for Logical Replication](/blog/postgres-19-feature-preview-logical-replication-sequence).

## MultiXact ceiling, eliminated

PostgreSQL tracks row-level locks shared across transactions in MultiXact structures. The pointer into the member array — MultiXactOffset — was 32 bits, capping total members at roughly 4 billion. Transaction-ID wraparound is well-known and widely monitored. MultiXact member exhaustion is not. It does not show up on standard XID-consumption dashboards. High-concurrency workloads with foreign keys can hit it in days, not years.

In May 2025, [Metronome experienced four separate outages](https://metronome.com/blog/root-cause-analysis-postgresql-multixact-member-exhaustion-incidents-may-2025) from this exact ceiling during a data migration, requiring hours of emergency vacuuming on a 30TB cluster.

PostgreSQL 19 widens MultiXact members to 64 bits. The ceiling is gone — not raised, eliminated.

**Why it's useful:** The "vacuum or die" emergency for member exhaustion is gone. The aggressive anti-wraparound vacuum that ran specifically against MultiXact member space is no longer needed; routine vacuum still matters for disk reclamation. Upgrading to 19 rewrites the `pg_multixact` SLRU files via `pg_upgrade` automatically; size the upgrade window accordingly on clusters with large multixact histories. Full background and the Metronome incident analysis: [Postgres 19 Feature Preview: 64-bit MultiXactOffset](/blog/postgres-19-feature-preview-64bit-multixactoffset).

## Vacuum

Two long-standing complaints land together. Autovacuum can use parallel workers. The `pg_stat_*` views expose enough state that diagnosing a slow vacuum no longer relies on guesswork.

**Parallel autovacuum.** `autovacuum_max_parallel_workers` enables parallel index processing for autovacuum runs. Per-table tuning lives in the new `autovacuum_parallel_workers` storage parameter. Manual `VACUUM (PARALLEL N)` has worked since 13; autovacuum has been single-threaded throughout.

**Autovacuum priority is now visible.** `pg_stat_autovacuum_scores` exposes _why_ a given table is queued ahead of another. A family of `autovacuum_*_score_weight` GUCs (covering freeze, vacuum, vacuum-insert, multixact-freeze, and analyze pressure) lets operators tune the priority function. Before 19, autovacuum picked tables in discovery order; tuning amounted to changing thresholds and hoping.

**`pg_stat_progress_vacuum` gains two columns.** `started_by` distinguishes `manual` / `autovacuum` / `autovacuum_wraparound`. `mode` distinguishes `normal` / `aggressive` / `failsafe`. Routine sweep or emergency, in one column.

**Planned vs launched parallel workers logged.** `VACUUM (VERBOSE)` output and autovacuum logs gain two numbers: how many parallel workers the operation planned, and how many it actually launched. The two diverge often. `max_parallel_maintenance_workers`, `min_parallel_index_scan_size`, the eligible-index count, and runtime worker availability all gate the count. Before 19, when launched fell below planned, no log evidence told you which gate closed.

**Why it's useful:** Faster autovacuum on heavily-indexed tables, with the feedback loop to verify it actually ran the way you expect. Parallel autovacuum gates on the same conditions as manual `VACUUM (PARALLEL N)` — eligible-index count, `min_parallel_index_scan_size`, available worker slots — so verify workers actually launch.

Investigation order changes too. The old loop — raise `maintenance_work_mem`, lower `autovacuum_vacuum_cost_delay`, hope — was guesswork because the inputs were not observable. The new sequence:

1. Read `pg_stat_autovacuum_scores` to confirm priority.
2. Check the autovacuum log for planned vs launched workers. If the gap is large, the bottleneck is gating, not throughput.
3. Watch `pg_stat_progress_vacuum.mode` for `failsafe` events. A failsafe cluster needs priority weights tuned, not more workers.

## Closing thoughts

`pg_plan_advice` is the one I'm most excited about, and it closes another long-standing gap with Oracle and SQL Server. `pg_plan_advice` defines an in-core hook for injecting planner advice, which is the foundation a proper SQL Plan Management (SPM) module can be built on — automatic baseline capture, plan evolution, regression detection, the pieces Oracle SPM and SQL Server's Query Store users have taken for granted for years. PostgreSQL 19 doesn't ship SPM itself, but for the first time it ships the substrate that lets the community build one without forking the planner.

The rest of the list is the kind of steady, hard-won progress that keeps PostgreSQL ahead in production. Vacuum and MultiXact are the same [(debatable) architectural choice](https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html) surfacing as different problems — to implement MVCC, PostgreSQL keeps a separate version of every row an `UPDATE` touches, and a background process cleans them up. Until something like [OrioleDB](https://www.orioledb.com/) — a storage engine that implements MVCC via undo log instead of duplicating tuples — lands in core, we will keep duct-taping.

## Further Readings

- [Postgres 19 release notes draft](https://www.postgresql.org/docs/devel/release-19.html)
- [The Part of PostgreSQL We Hate the Most](https://www.cs.cmu.edu/~pavlo/blog/2023/04/the-part-of-postgresql-we-hate-the-most.html)
- [Clerk: February 2026 outage postmortem caused by query plan flip](https://clerk.com/blog/2026-02-19-system-outage-postmortem)
- [Metronome: May 2025 PostgreSQL MultiXact member exhaustion](https://metronome.com/blog/root-cause-analysis-postgresql-multixact-member-exhaustion-incidents-may-2025)



Our auditor came back with a note on one of the controls — *Administrator account use is logged for retrospective investigation if required*. It maps to SOC 2 Trust Services Criteria CC6.1 (logical access), CC6.3 (access changes), and CC7.2 (system monitoring) — the "admin activity" slice of those controls.

The feedback was short:

> Thank you for providing log and alert configurations. To complete testing, we need evidence that administrator activity is actually logged (not just that logging is enabled). Could you please provide a sample from GCP Audit Logs showing the four mandatory fields.

The auditor's four fields:

- an admin/privileged user
- the action performed
- timestamp
- affected resource

Reading it, I realized something we had taken for granted. We had audit logging turned on everywhere. We could show every configuration page in GCP. What we did not have, immediately, was a clean sample of an admin doing an admin thing — captured, queryable, and attributable.

That one note reshaped how I think about audit logs. This post is what I wish I had read before our audit.

## "Logging Enabled" Is Not "Audit Evidence"

Most teams think about audit logs as a configuration problem. Turn on `pgaudit`. Enable the MySQL general log. Flip on GCP Cloud Audit Logs. Check the box in the SaaS admin panel.

That is the easy half.

The hard half is what the auditor actually asks: *can you produce a concrete record, right now, of an administrator performing a privileged action, with user + action + timestamp + affected resource*?

Auditors do not grade your configuration page. They grade the log sample you hand them. If your logging is enabled but the log itself is empty, malformed, or missing one of those four fields, the control is incomplete.

The gap almost always lives in one of three places:

1. **Logging is enabled but the events aren't captured** — the category of action the admin did isn't one the logger records.
2. **The events are captured but the identity is wrong** — a shared service account ran the action, so "who" is ambiguous.
3. **The events are captured but the resource is implicit** — the log says "policy updated" but not *which* policy.

This control is specifically about administrator activity, which is where these gaps are worst. Admin actions tend to be rare, privileged, and hit the layers of the system that product engineers instrument last.

## What Auditors Mean by "Administrator Activity"

In the context of a database access platform like Bytebase, an administrator is anyone who can change the rules by which other users operate. That covers more than you think:

- **Workspace administrators** — provision instances, manage global settings
- **DBAs** — configure environments, set up approval flows, manage masking policies
- **Project owners** — grant database access, assign roles, approve changes in their project
- **SSO / identity administrators** — change authentication configuration, rotate SSO providers
- **Anyone with a custom role that includes a privileged permission** — the long tail

When the control says "administrator account use is logged," it means *every* one of those roles performing *every* privileged action needs a log entry with the four mandatory fields.

The auditor is not asking for a firehose of queries. They are asking for the specific slice of activity that changes the security posture of the system — grants, revokes, policy edits, identity changes, and the rare break-glass deployment.

## Four Fields, Six Categories

The auditor's checklist — user, action, timestamp, affected resource — is the minimum. To actually pass this control for a database access platform, every one of the following categories has to produce that same four-field record:

### 1. Authentication events

Every login, every SSO handoff, every failed attempt, every session termination. A successful login from a new IP is an audit event. A failed 2FA challenge is an audit event. A session ending by timeout is an audit event — because "when did this admin's session end" is a question auditors will ask during an incident investigation.

### 2. Role and permission changes

Grants and revokes at the workspace level, project level, and database level. The record must capture *who was granted what permission on what resource by which admin, and when*. "Alice granted Bob database `prod-orders` read access" is one line; the mistake is storing it as "Alice changed a setting."

### 3. Policy changes

SQL review rules, approval flow definitions, masking rules, data classification settings, retention policies, allowlists. Every edit is an administrative action that changes what the rest of the platform will do. Each edit needs a before/after, or at minimum a pointer to the change record.

### 4. Access request decisions

Who requested access, who granted or denied it, under what justification, with what expiration. This is the audit trail for Just-In-Time access — a pattern auditors increasingly expect, because standing access is a finding in its own right.

### 5. Data exposure events

Query exports, masking exceptions (who unmasked what under what approval), sharing a query sheet with an external user. These are the "the data left the safe perimeter" events, and auditors trace them first during an incident response test.

### 6. Change execution

Deploys, rollbacks, manual SQL execution in Admin Mode, bypasses of the normal approval flow. Every execution needs a line. Admin Mode in particular — the break-glass path — is where most teams fail. People skip the logging conversation exactly when it matters most.

Each of these six categories maps to a SOC 2 Trust Services Criterion. CC6.1 covers logical access, CC6.3 covers access changes, CC7.2 covers system monitoring. The "administrator activity" control sits inside your organization's implementation of those criteria and is specifically the "admin" slice.

## Why Database-Native Logs Are Not Enough

When we first looked at this control, the instinct was to point at database audit logs. Postgres has `pgaudit`. MySQL has the general log. SQL Server has audit specifications. Oracle has unified auditing.

They are all useful. None of them answer the control for a platform.

A database-native log captures the SQL that ran. It does not capture:

- **Who approved that SQL to run** — the approver is outside the database layer
- **Under what policy the SQL was allowed** — the SQL review rules that the statement passed through
- **Whether the person was accessing on behalf of themselves or via a granted role** — the request chain
- **What access request led to this session** — the Just-In-Time history
- **Why a masking exception was permitted** — the approval behind an unmasked read

Database audit logs tell you *what ran*. Platform audit logs tell you *who authorized it, under what policy, and whether that authorization is still valid*. A SOC 2 auditor asking "show me a week of admin activity with user + action + timestamp + resource" needs the second one.

If your architecture is application → database, with nothing in between, the database log is most of what you have and you instrument around it. If there is a platform between users and the database — Bytebase, Okta Privileged Access, StrongDM, Teleport, a homegrown bastion — that platform needs its own audit log that is at least as rigorous as the database's.

## What We Built in Response

After the auditor's note, we did two things.

First, we audited our own audit log. We took the six categories above and walked through each one to see whether a query against the log could reproduce the user + action + timestamp + resource tuple for every event type. A handful of admin actions — mostly in SSO configuration and workspace-level settings — were captured but in an older, less structured format. We normalized them.

Second, we made the log easier to hand to an auditor. [Bytebase's Audit Log](https://docs.bytebase.com/security/audit-log) now supports filtering by user, action type, resource, and time range in the GUI, and export to JSON or CSV for ingestion into a SIEM. When the next audit cycle comes around, the evidence is a filtered export, not a screenshot of a config page.

The concrete change was small. The mental model change was larger. "Logging enabled" is a system property. "Audit evidence" is an artifact — and you have to produce it on demand. The design decision that follows is: every admin-class action in the system must produce a log record by construction, not as a side effect.

That was our own compliance story — Bytebase as a company passing its own SOC 2 audit. The same lesson applies to our customers. Bytebase sits between developers and databases, so every schema change, data query, access grant, and policy edit flows through the platform. The audit log gives teams the same four-field record (user + action + timestamp + resource) for every database operation. When *their* auditor asks "who changed the production schema on March 14, and who approved it?" the answer is a filtered export, not a scramble through Slack and Jira.

## If You're Evaluating a Database Access Platform

If you are buying a database access platform and you care about SOC 2, ask the vendor:

1. **Show me a sample audit log export.** Not a config page. Not a screenshot. A real export with at least a week of activity.
2. **Can I filter to just administrator activity?** If the answer involves grep, the log is not structured enough for audit.
3. **Does the log include: user identity, action name, timestamp, and affected resource — on every row?** If any row is missing one of those, the log fails the control on that row.
4. **How long is the retention, and is it tamper-evident?** SOC 2 does not prescribe a specific retention period, but 12 months is a common baseline and some auditors want 7 years for specific control categories.
5. **Can I export to a SIEM?** If the platform log lives only in the vendor's UI, you cannot correlate it with the rest of your security telemetry, which auditors increasingly expect.
6. **Are break-glass paths (Admin Mode, emergency access, bypass roles) logged with the same fidelity as normal paths?** This is the most common gap.

## The Checklist

If you are going through SOC 2 right now, here is the short version of what the administrator activity control requires:

- [ ] Every admin role in the system is enumerable (workspace, project, database, custom)
- [ ] Every privileged action each of those roles can perform has a corresponding log entry type
- [ ] Every log entry captures user, action, timestamp, affected resource — no exceptions
- [ ] The log is queryable by user, by action, by resource, by time range
- [ ] A week-long sample can be exported and handed to an auditor without post-processing
- [ ] Break-glass paths are logged with the same four fields
- [ ] Retention is at least 12 months and is tamper-evident
- [ ] The log can be ingested into your SIEM

The difference between "we have logging" and "we can pass the audit" lives in whether you can put a check next to every line above, today, without scrambling.

## FAQ

### Can I use GCP Audit Logs / AWS CloudTrail / Azure Monitor as my audit log?

For infrastructure-level administrator activity, yes. Those cloud audit logs capture IAM changes, resource creation, console logins, etc. They do not capture application-level administrator activity — role grants inside your SaaS, SQL review policy edits, or access request approvals. For a database access platform, you need the platform's own audit log in addition to the cloud-native log.

### Is database audit logging enough for SOC 2?

It's necessary for database-layer activity but not sufficient. Database logs miss the platform-level context — approvals, access requests, policy changes, identity events — that SOC 2 controls on logical access and monitoring require. If your architecture has a platform layer between users and the database, the platform layer needs its own audit log.

### How much retention do I need?

SOC 2 doesn't mandate a specific retention period — auditors look at what your own policy states and whether you meet it. Twelve months is the common default; regulated industries often require longer (SOX, HIPAA, PCI DSS each have their own stricter requirements). Whatever you commit to in your policy, your log infrastructure must actually deliver.

### What's "tamper-evident"?

An audit log that can detect after-the-fact modification. Implementations range from append-only storage (immutable S3 buckets, WORM) to cryptographic chains (each log entry includes a hash of the previous). SOC 2 doesn't prescribe the mechanism; auditors want to see that deletion or modification would be detectable.

### What about non-admin user activity?

Separate controls. The administrator activity control is specifically about privileged accounts. General user activity (queries, data access) falls under other controls — CC6.1 (logical access) for authentication, CC6.7 (data transmission) for exfiltration paths, CC7.2 (monitoring) for anomaly detection. The principle is the same: log enablement is necessary but not sufficient; evidence is what passes audit.

---

Related reading:

- [Database Audit Logging: Two Layers, One Trail](/blog/database-audit-logging) — the hub post, with the infrastructure-vs-workflow split
- [How Bytebase Handles Audit Logging](/blog/bytebase-audit-logging) — what gets recorded, the schema, and how to export
- [Postgres Audit Logging Guide](/blog/postgres-audit-logging) — engine-native options for PostgreSQL
- [SOC 2 Data Security and Retention Requirements](/blog/soc2-data-security-and-retention-requirements)
- [Database Change Management for SOX Compliance](/blog/database-change-management-sox-compliance)
- [Database Access Control Best Practices](/blog/database-access-control-best-practices)
- [What is Database Change Management](/blog/what-is-database-change-management)



Eighteen months before a fintech files its S-1, a partner from a Big Four accounting firm walks into a conference room and asks one question:

_"Show me every database change made to your financial reporting systems in the last 12 months. Who approved each one, and why."_

Most engineering teams **cannot answer this**. They have git history for application code. But database changes — the DML statements that modify transaction records, the DDL that restructures tables holding financial data — might have a Jira ticket somewhere, but nobody can tell you whether the SQL was actually executed, by whom, or whether the final statement matched what was approved.

This is where database change management meets SOX compliance. And the gap costs companies **6 to 12 months of IPO delay** when auditors find it.

## What SOX actually requires for database changes

The Sarbanes-Oxley Act (SOX) is a US federal law passed in 2002 after the Enron and WorldCom accounting scandals. It requires every publicly traded company to maintain internal controls over financial reporting and have those controls audited annually. Any company filing for a US IPO must have SOX controls in place before submitting its S-1.

Section 404 is the part that hits engineering teams. If your databases touch financial data, they are in scope. The assessment maps to four [IT General Control (ITGC)](https://pathlock.com/learn/itgc-sox-the-basics-and-6-critical-best-practices/) domains:

| ITGC domain | What auditors check |
|---|---|
| **Change management** | Every DDL/DML change authorized before execution and linked to a ticket of record (Jira, ServiceNow, or an internal system). The person who writes the SQL cannot be the same person who approves it. |
| **Access controls** | No shared `root` or `admin` accounts. Role-based access tied to an identity provider. Quarterly access reviews documented. |
| **[Audit trail](/blog/database-audit-logging/)** | Full history: the actual SQL statement, who requested it, who approved it, the business justification, and the timestamp. |
| **Program development** | Changes flow through dev, staging, production with testing evidence at each stage. No direct-to-prod SQL. |

One detail that catches companies off guard: auditors typically want 12 to 18 months of continuous evidence. If you deploy controls six months before your filing, you do not have enough history. Start SOX ITGC preparation at least 18 months before your expected IPO date. Not 12. Not 6.

## Six questions your auditors will ask

These come from real ITGC audit procedures.

| Auditor's question | Why teams fail | What passing looks like |
|---|---|---|
| _Who ran this DML on the production financial database on March 14th?_ | Shared credentials. Every action attributed to `db_admin`, not a named person. | Every database action tied to an individual identity through SSO. |
| _Show me the approval chain for this schema change._ | Approvals happen in Slack or standups. Auditors need a system of record, not chat screenshots. | Change request workflow where approvals are recorded before SQL executes. |
| _Can someone with write access also approve their own changes?_ | Same DBA writes and deploys SQL, or one person holds both `admin` and `approver` roles. | Role-based workflows where requester and approver are different people, enforced by the system. |
| _Show me evidence that this change was tested before production._ | Engineers run SQL directly against production. No staging, no dry run, no evidence. | Multi-environment pipeline with execution logs at each stage. |
| _List all users with write access to financial databases, when granted, and when last reviewed._ | Access managed through ad-hoc `GRANT` statements with no review records. | Centralized [access management](/blog/database-access-governance/) with provisioning logs and quarterly reviews. |
| _Which Jira ticket authorized this `DELETE` on the production ledger?_ | Changes run without a linked ticket, or engineers mark tickets done manually after the fact — with no guarantee the SQL that ran matches what the ticket approved. | Every change references an approved ticket ID from the start, and the ticket updates automatically when the SQL executes or fails. |

If your team cannot answer all six today, the question is whether you discover the gap now or your auditor discovers it during fieldwork.

## How to build SOX-compliant database change controls

The fix is not buying a tool and hoping it generates the right reports. It is restructuring how database changes flow through your organization so that compliance evidence is a byproduct of the process.

**Step 1: Centralize all database changes through a single control plane.**

Stop making changes through direct database connections. Route every DDL and DML statement through a system that enforces policy before execution. [Bytebase](/) does this by creating a single entry point for all database changes across instances (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server) with built-in approval workflows that produce the audit trail auditors need.

**Step 2: Implement risk-based approval workflows.**

Not every change needs the same scrutiny. Adding a column to a staging table is different from running `DELETE FROM transactions WHERE...` on production. High-risk DML on financial tables gets multi-level approval. Low-risk DDL in non-production environments passes through faster. This maps directly to ITGC change management without creating bottlenecks.

**Step 3: Link every change to a ticket of record.**

Most SOX-bound teams already require that every database change maps to an approved ticket — typically in Jira, but ServiceNow or an internal tracker works the same way. The trap is doing it manually: an engineer opens a ticket, runs the SQL through a separate tool, then marks the ticket done by hand. That manual step is exactly where traceability breaks — tickets get forgotten, the ticket ID never matches the SQL that actually ran, and approval evidence ends up scattered across Slack threads and source control PRs. Automate the link instead: the change request carries the ticket ID from the moment it is filed, GitHub-based approvals flow back onto the ticket, and the ticket transitions automatically when the SQL executes or rolls back. When the auditor asks which Jira issue authorized a specific production `DELETE`, the answer is one click, not an archaeology project.

**Step 4: Enforce SQL review rules.**

Block `DELETE` without a `WHERE` clause. Require `LIMIT` on DML affecting production. Flag `DROP TABLE` for executive-level approval. These are preventive controls — they stop dangerous statements before execution, which auditors rate higher than detective controls that only alert after the fact.

**Step 5: Deploy identity-aware access controls.**

Connect database access to your identity provider (Okta, Azure AD). When someone leaves or changes roles, their database access updates automatically via SCIM. Every query traces back to a named user, not a generic service account.

**Step 6: Generate auditor-ready evidence.**

Your database change management system should produce exportable reports on demand: every change, who requested it, who approved it, when it ran, and the actual SQL. Do not reconstruct this from logs after an auditor asks.

Financial services companies often require that no customer data leaves their infrastructure. On-premises deployment keeps the change management platform inside your security boundary. See how [PayerMax built security and compliance into their database workflow](/customers/payermax) with a similar approach.

## Timeline: when to start

Companies that start late face a binary choice — delay the IPO or accept a material weakness finding. Neither is cheap.

- **T-18 months:** Gap assessment. Map every database touching financial reporting. Identify shared credentials, undocumented changes, missing audit trails.
- **T-12 months:** Deploy centralized [database change management](/blog/what-is-database-change-management/). Start accumulating audit history.
- **T-9 months:** Internal test audit. Can you answer the five questions above?
- **T-6 months:** External auditor pre-assessment. You want findings now, not during the real audit.
- **T-3 months:** Remediate remaining findings. Lock down controls.
- **IPO filing:** Present 12-plus months of continuous ITGC compliance evidence.

Companies in the EU should also account for [DORA (Digital Operational Resilience Act)](https://www.digital-operational-resilience-act.com/) requirements, which add ICT risk management and incident reporting obligations on top of SOX controls. Learn more about [Bytebase for financial services](/industry/financial-services).



Data management tools cover a wide spectrum — from the GUI client you use to run queries to the pipeline moving data into your warehouse. The 10 tools below are the ones developers, DBAs, and data engineers reach for most in 2026, organized by category: database clients, schema migration, pipelines, transformation, and analytics.

## What are data management tools?

Data management tools are software that helps teams store, organize, migrate, monitor, and govern data across its lifecycle. The category includes database clients for running queries, schema migration tools for applying and tracking structural changes, pipeline tools for moving data between systems, and analytics platforms for reporting.

The right tool depends on where you sit in the stack. A developer needs a GUI client and a migration tool. A data engineer needs pipelines. An analyst needs a BI platform. Most teams use several tools from different categories rather than one that covers everything.

## Categories of data management tools

| Category | What it solves | Tools in this guide |
|----------|---------------|---------------------|
| Database GUI clients | Query, explore, and manage database contents | DBeaver, TablePlus, pgAdmin, DataGrip |
| Schema migration & change management | Version-control and deploy schema changes | Bytebase, Liquibase, Flyway |
| Data pipelines | Move and sync data between systems | Airbyte |
| Data transformation | Model and transform data in the warehouse | dbt |
| Analytics & BI | Query and visualize data for reporting | Metabase |

## Database GUI clients

A database GUI client connects to one or more databases and gives you a visual interface for running queries, browsing tables, editing data, and inspecting schema. They don't manage schema changes (that's a migration tool's job), but they're the primary tool most developers and DBAs use for daily database work.

### DBeaver

![DBeaver query editor with multi-database connection tree and ER diagram panel](/content/blog/top-data-management-tools/dbeaver-screenshot.webp)

DBeaver is an open-source database client that connects to over 100 databases, including PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, and Snowflake. The interface includes an ER diagram editor, bulk data export, and a visual query builder.

**What it does well:** More database engine support than any other client on this list. The free Community edition covers querying, schema browsing, and ER diagrams. The ERD viewer renders table relationships visually, useful when mapping an unfamiliar schema.

**Limitations:** The interface is dated and can be slow on large result sets. Git integration, data masking, and role management require the commercial Enterprise edition.

**Pricing:** Free Community edition. DBeaver Pro from $99/user/year, Enterprise from $249/user/year.

### TablePlus

![TablePlus tabbed interface showing table data and inline editing](/content/blog/top-data-management-tools/tableplus-screenshot.webp)

TablePlus is a native macOS, Windows, and Linux client built for speed and simplicity. It connects to PostgreSQL, MySQL, SQLite, Redis, MongoDB, and several others. Unlike Electron-based tools, TablePlus is a native app, which makes it noticeably faster to open and navigate.

**What it does well:** Clean, minimal UI that doesn't get in the way. Fast performance, even with large datasets. Inline editing and a tabbed interface work well for multi-database workflows.

**Limitations:** The free tier is limited to two open tabs and two open connections. Linux ARM support is absent. Fewer advanced features than DBeaver.

**Pricing:** Free tier available. Subscription from $59/year per seat.

### pgAdmin

![pgAdmin dashboard showing PostgreSQL server status and query tool](/content/blog/top-data-management-tools/pgadmin-screenshot.webp)

pgAdmin is the standard open-source administration tool for PostgreSQL. It runs in a browser and can be self-hosted alongside a Postgres instance. The official PostgreSQL Docker image includes pgAdmin.

**What it does well:** PostgreSQL-specific features that generalist clients don't cover: tablespace management, replication status, VACUUM analysis, and a detailed query plan visualizer. Free and open source.

**Limitations:** PostgreSQL only. The interface is functional but less polished than commercial alternatives. Setup for remote instances requires some configuration.

**Pricing:** Free and open source.

### DataGrip

![DataGrip SQL editor with inline error detection and schema-aware autocompletion](/content/blog/top-data-management-tools/datagrip-screenshot.webp)

DataGrip is JetBrains' database IDE. It integrates tightly with the rest of the JetBrains toolchain (IntelliJ IDEA, PyCharm) and brings IDE-grade features to SQL editing: inline error detection, refactoring support, and Git integration.

**What it does well:** Smart SQL autocompletion that understands schema context. Inline warnings for common errors before execution. Useful for developers already working in JetBrains tools.

**Limitations:** Commercial only, with no meaningful free tier. Resource usage is higher than native clients.

**Pricing:** $229/user/year standalone; included in the JetBrains All Products Pack at $309/year.

| Tool | Best for | Open source | Pricing |
|------|----------|-------------|---------|
| DBeaver | Multi-database, budget-conscious teams | Yes (Community) | Free / from $99/yr |
| TablePlus | macOS/Windows, clean UI | No | Free tier / from $59/yr |
| pgAdmin | PostgreSQL administration | Yes | Free |
| DataGrip | JetBrains users, SQL IDE | No | From $229/yr |

## Schema migration and change management

Schema migration tools version-control your database structure (table creation, column changes, index additions) so modifications are reproducible and deployable across environments without manual coordination.

### Bytebase

![Bytebase schema change review workflow showing issue detail, SQL diff, and approval controls](/content/blog/top-data-management-tools/bytebase-screenshot.webp)

Bytebase is a [database change management](/blog/what-is-database-change-management/) platform built for teams. Where Flyway and Liquibase handle the mechanics of running SQL scripts, Bytebase wraps those mechanics in a structured workflow: developers submit schema changes, DBAs review them through a built-in approval system, and changes deploy across environments in sequence (dev → staging → production).

**What it does well:** Supports PostgreSQL, MySQL, SQL Server, Oracle, MongoDB, ClickHouse, and over 20 other databases from a single interface. SQL review rules run automatically on every submitted change, catching naming violations, risky operations, and missing indexes before review. Access control determines who can query or modify which database, and just-in-time access lets engineers request temporary elevated permissions. The full change history doubles as an audit trail for compliance.

**Limitations:** More setup than a CLI-only migration tool. Better suited to teams than solo developers. The collaboration features add overhead if only one person is making schema changes.

**Pricing:** Free Community edition. Pro and Enterprise plans for larger teams and organizations.

### Liquibase

![Liquibase changelog file and CLI output showing applied changesets](/content/blog/top-data-management-tools/liquibase-screenshot.webp)

Liquibase is an open-source schema migration tool that uses XML, YAML, JSON, or SQL changelogs to define and track database changes. It records which changesets have run, in what order, and against which database, then applies only the missing ones.

**What it does well:** Over a decade old, with integrations for most CI systems and build tools. Supports most relational and some NoSQL databases. The changelog format (XML, YAML, JSON, or SQL) produces a structured, auditable record of every change.

**Limitations:** CLI-first with no native web UI or approval workflow for team review. The open-source edition lacks rollback automation and some enterprise controls that are standard in Bytebase's free tier.

**Pricing:** Open-source Community edition free. Liquibase Pro from approximately $5,000/year.

### Flyway

![Flyway CLI output showing migration history and applied versioned scripts](/content/blog/top-data-management-tools/flyway-screenshot.webp)

Flyway applies versioned SQL migration scripts in sequential order. The mental model is simple: name your scripts `V1__description.sql`, `V2__description.sql`, and Flyway runs the ones that haven't been applied yet.

**What it does well:** Low learning curve. Fast to integrate into an existing project or CI pipeline. Good Spring Boot and Maven support.

**Limitations:** No web UI or team workflow. Rollback support is manual in the Community edition. Does not enforce change review or access controls.

**Pricing:** Open-source Community edition free. Flyway Teams from approximately $90/user/year.

For a detailed comparison of these two migration tools, see [Flyway vs. Liquibase](/blog/flyway-vs-liquibase/).

| Tool | Approach | Team workflow | Open source |
|------|----------|--------------|-------------|
| Bytebase | Web UI + API, full DevSecOps | Yes (review, approval, access control) | Yes (Community) |
| Liquibase | Changelog files (XML/YAML/SQL) | No (CLI-based) | Yes (Community) |
| Flyway | Versioned SQL scripts | No | Yes (Community) |

## Data pipelines

### Airbyte

![Airbyte connection dashboard showing source-to-destination sync status and connector catalog](/content/blog/top-data-management-tools/airbyte-screenshot.webp)

Airbyte is an open-source data integration platform that extracts data from source systems (databases, SaaS APIs, files) and loads it into destinations like data warehouses, lakes, or databases. It has over 550 pre-built connectors and supports building custom ones through a low-code framework.

**What it does well:** One of the largest connector catalogs available, with an active open-source community that adds and maintains connectors. CDC (Change Data Capture) support lets you sync incremental changes from databases rather than doing full reloads. Self-hostable for teams that can't send data through a vendor's infrastructure.

**Limitations:** Self-hosting requires operational setup and ongoing maintenance. Some community-maintained connectors lag behind source API changes. The managed cloud version costs more at scale than building direct integrations for simple use cases.

**Pricing:** Open-source self-hosted free. Airbyte Cloud starts at $10/month (consumption-based).

## Data transformation

### dbt

![dbt lineage graph showing model dependencies and transformation pipeline](/content/blog/top-data-management-tools/dbt-screenshot.webp)

dbt (data build tool) lets analysts and engineers write SQL SELECT statements to define how data should be modeled in a warehouse. It compiles those models into the appropriate SQL dialect, runs them against the warehouse (BigQuery, Snowflake, Redshift, DuckDB, and others), and generates documentation and lineage graphs automatically.

**What it does well:** Brings software engineering practices (version control, testing, documentation, modular design) to analytics SQL. A large library of community packages covers common transformations. The lineage graph makes it easy to trace how any metric is derived.

**Limitations:** Works only on data already in a warehouse. dbt does not move data. You need a pipeline tool like Airbyte upstream to land the raw data. Requires SQL proficiency; it is not a low-code tool.

**Pricing:** dbt Core is open source and free. dbt Cloud (hosted, with a UI and scheduling) starts at $100/month.

## Analytics and BI

### Metabase

![Metabase dashboard builder showing charts and a question editor with no SQL required](/content/blog/top-data-management-tools/metabase-screenshot.webp)

Metabase is an open-source BI tool that lets non-technical users build charts and dashboards through a point-and-click interface, without writing SQL. Developers can also drop into a SQL editor for custom queries.

**What it does well:** Non-technical users can build basic dashboards without writing SQL. Straightforward to self-host. Embedding support lets you surface dashboards inside a product.

**Limitations:** SSO, audit logs, data sandboxing, and permission groups are in the paid commercial edition. Performance can degrade with large result sets or complex queries against unoptimized tables.

**Pricing:** Open-source Community edition free (self-hosted). Metabase Pro starts at $500/month for 10 users.

## How to choose the right data management tool

The right stack depends on your role and where the problem is:

**Developers and DBAs managing schema changes** need a migration tool and a database client. If your team needs approval workflows, SQL review automation, and audit trails for schema changes, Bytebase handles all of that in one place and can replace both the migration CLI and the manual change coordination process. For teams that prefer simpler CLI tools with fewer moving parts, Flyway or Liquibase cover the migration mechanics. See [the security stack around database change](/blog/top-database-change-management-tools/) for a more detailed breakdown.

**Data engineers building pipelines** need an EL tool like Airbyte. If the destination is a data warehouse and you need to transform raw data into analytics-ready models, pair Airbyte with dbt. These two tools are commonly deployed together.

**Analysts and product teams** need a BI tool like Metabase. If your analysts write SQL directly and need a full-featured client, DataGrip or DBeaver work well here too.

GUI clients and CLI migration tools cover the technical mechanics of querying and deploying changes, but neither handles the coordination layer: who approves a change before it hits production, which environment it deploys to first, who has query access to what. Bytebase covers that layer with approval workflows, staged deployments, and a full audit trail. See [top database DevOps tools](/blog/top-database-devops-tools/) for where change governance fits in a DevOps stack.

No single tool covers the full stack, but most teams only need 3–4 of these categories. Start with what's costing your team the most time: if schema changes are slow or risky, a migration tool is the priority. If analysts are blocked waiting for data, a pipeline tool is. If dashboards are fragile or hard to share, a BI platform helps. Build from there.


The
Bytebase Blog

Explore the standard for database development

Solutions & Platform

Comparisons

Legal

Resources

Company