What a database MCP server actually hands an AI agent, how a query runs through one, and why a raw connection-string server is fine on your laptop but risky against production.

What is a Database MCP Server?

A practical comparison of the Postgres MCP servers worth running in 2026 — Postgres MCP Pro, Supabase, Google MCP Toolbox, AWS, DBHub, and Bytebase. We look at vendor lock-in, database scope, access model, and governance to help you pick the right one.

Governed MCP vs. Raw MCP: How Agents Reach Your Database

AI agents are no longer just reading your database, they are authoring the migrations. The write path is a different risk class, and it needs its own gate.

When the Agent Writes the Migration, Who Approves It?

Generic PAM controls the database connection. Database PAM controls the SQL statement: per-query authorization and approval, SQL review, data masking, and statement-level audit. What the category means and why it exists.

What is Database PAM (Privileged Access Management)?

How to run SQL Server schema migrations safely in production, covering state-based vs migration-based workflows, online index operations, batched backfills, the expand-and-contract pattern, and CI/CD.

SQL Server Schema Migration and Change Management

CyberArk is a broad privileged access management (PAM) platform. Bytebase is a database-specific PAM for access control, masking, and SQL review. If you already run CyberArk, here is why you still need it for the database.

Bytebase vs. CyberArk: the database vertical in your PAM stack

How to store, rotate, and scope database credentials: secrets managers, dynamic credentials, the application path vs the human path, and the mistakes that leak passwords.

Managing Database Passwords and Secrets: Best Practices

The practical ways to audit MySQL activity, from the general query log to audit plugins, binlog CDC, and Bytebase, and where each one falls short.

MySQL Audit Logging Guide

Every critical asset has its system of record, except the database. Bytebase is the one. The standard for database development.

The Standard for Database Development

Dynamic data masking is chosen by access path, not product. Five approaches (engine-native, in-database, application, BI layer, and Bytebase) and which caller each one masks.

How to Implement Dynamic Data Masking: Five Approaches by Access Path

Static vs dynamic data masking, when each applies, how they differ on backups, performance, and reversibility, and when to run both.

Static vs Dynamic Data Masking: When to Use Which

The static data masking tools that produce safe non-production data, Delphix, Tonic.ai, and greenmask compared, plus how to roll your own when no tool fits.

Static Data Masking Tools (and How to Roll Your Own)

Compare BigQuery data masking options: native column-level dynamic data masking (built-in masking rules via policy tags and data policies, Dataplex catalog) and Bytebase fleet-wide masking.

BigQuery Dynamic Data Masking

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)?

How to run dynamic data masking so it survives an audit: mask by role, go column-level, log unmask events, review policy changes in code, and keep environments in sync. Plus a vendor comparison and an end-to-end walkthrough.

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 the database connection. Databases also need SQL review, a schema change workflow, and per-statement approval. Here is where PAM stops and why most teams run it alongside 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

A side-by-side look at Bytebase and Atlas for database schema migration: how each one approaches migrations, their CI/CD and access control, supported databases, and what they cost. Updated for Atlas v1.1 and Bytebase 3.16.

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

Database access control practices that hold up in a SOC 2 audit: least privilege, separation of duties, just-in-time access, statement-level enforcement, and the common mistakes that get flagged.

Database Access Control (DAC) Best Practices

A practical look at what SOX Section 404 expects from database changes: the four ITGC domains, the six questions auditors actually ask, and how to make compliance evidence a byproduct of your workflow.

Database Change Management for SOX Compliance

TRUNCATE and DELETE both remove rows, but they differ in speed, rollback behavior, and locking. Here is how each one behaves in PostgreSQL, MySQL, and SQL Server, and when to reach for which.

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

A practical walk through six database design patterns you will actually meet in production: normalization, star schema, EAV, polymorphic associations, multi-tenancy, and the anti-patterns worth avoiding.

Database Design Patterns Every Developer Should Know

A practical walkthrough of pgvector: installing the extension, storing embeddings, writing similarity queries, building HNSW indexes, and knowing when plain PostgreSQL is enough.

pgvector: How to Add Vector Search to PostgreSQL

How upsert works across MySQL, PostgreSQL, and SQL Server, with the syntax for each, the edge cases worth knowing before you ship, and how upserts interact with migrations.

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

How to find and fix slow MySQL queries: reading the slow query log, using EXPLAIN, tuning indexes, and rewriting queries, with a worked example for each.

How to Fix Slow MySQL Queries: A Practical Guide

Convex and Supabase are both backend-in-a-box platforms, but built on different foundations. This post compares their architecture, real-time model, data model, schema management, and pricing to help you decide.

Convex vs Supabase: Which Backend Platform Should You Choose?

Blue-green deployment is easy when your servers are stateless. The trouble starts at the database. This guide walks through why database blue-green is hard and how to do it without corrupting your data.

Database Blue-Green Deployment: A Practical Guide

A look at 10 data management tools developers and data engineers actually use in 2026: GUI clients, schema migration, pipelines, and analytics, with pricing for each.

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

A look at three SQL editors built only for Postgres, with what each one is good at and who it fits, to help you pick the right one in 2026.

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

A practical look at the database deployment tools DevOps teams actually use in 2026, sorted by how each one defines, applies, and coordinates schema changes.

Database Deployment Tools for DevOps Teams in 2026

A walk-through of how renaming a single column can quietly break an analytics pipeline, why it happens, and how schema change detection and notification help you catch it early.

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

How to read a Postgres query plan, spot the common performance problems, and fix them without breaking other queries.

Postgres Query Plan: How to Read and Fix Performance Issues

A walk through every layer of the Postgres permission system that can raise ERROR 42501, why each one fires, and how the behavior differs from MySQL.

The Anatomy of Postgres Permission ERROR 42501

A practical look at Postgres logs: what they record, how the logging collector works, which parameters actually matter in production, and the mistakes that turn logs into expensive noise.

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

How to run MySQL schema migrations without blocking queries or causing downtime, covering the MySQL-specific behaviors that bite in production and the tools that work around them.

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

What multi-environment database deployment actually involves, the problems teams keep hitting, and the patterns (manual scripts vs GitOps) for handling them.

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 really has two layers: the infrastructure layer your cloud provider ships, and the workflow layer you have to build yourself. Here is what each one captures, and why an audit needs 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

What the "Require Primary Key" SQL review rule checks, the production problems a missing primary key tends to cause, and the SQL to fix tables that don't have one.

Require Primary Key: A SQL Review Rule Explained

What the "Enforce NOT VALID in CHECK" SQL Review rule does, why adding a CHECK constraint can lock your table, and how the two-step NOT VALID approach avoids it.

Enforce NOT VALID in CHECK: A SQL Review Rule Explained

The practical ways to audit a PostgreSQL database, from native logging to triggers, logical replication, pgAudit, and Bytebase, with the trade-offs of each.

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 walkthrough of moving each Supabase piece (database, auth, storage, functions, realtime, networking) to its AWS counterpart, with a services-first order that keeps the final database cutover simple.

How to Migrate from Supabase to AWS

Six open-source PostgreSQL backup tools compared for 2026, with the language, license, interface, and best-fit use case for each, plus a note on which ones are still maintained.

What is Enterprise Database Management (EDM)?

A plain explanation of Postgres Transaction ID (XID) wraparound: what causes it, how to check how close you are, and what keeps it from taking your database offline.

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 with PostgreSQL, covering my day-to-day development workflow, the tools I actually use, and real-world examples

How I Ship Features with Postgres

A practical look at what LGPD (Brazil's General Personal Data Protection Act) means for database operations, how it differs from GDPR, and the controls teams need to actually comply.

Database Compliance for LGPD: Implications and Best Practices

What a Postgres LATERAL JOIN does, when to reach for one, and the patterns and gotchas you'll run into using it.

What is Postgres LATERAL JOIN?

What MySQL Online DDL actually does, how its three algorithms (INSTANT, INPLACE, and COPY) differ, and the limitations to plan around before you run a schema change in production.

MySQL Online DDL: A Practical Guide

A practical look at the leading open-source Postgres connection poolers, with what each is good for and how to pick a pooling mode.

Open Source Postgres Connection Pooler

Should your tables be named user or users? This post walks through the trade-offs of singular vs. plural table naming, what the common stacks default to, and a set of conventions you can copy into your own handbook.

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 on edition gate, policy management, and audit trail.

Snowflake Dynamic Data Masking (DDM) and Alternatives

A look at the open-source ways to add authentication and authorization to a Postgres app in 2025, from all-in-one platforms to libraries, identity servers, and the minimalist JWT-to-RLS pattern, with a "best for" note on each.

Postgres Case Sensitivity Explained

What pg_database_owner does in Postgres, why it was added, and how to use it without hitting the "cannot have explicit members" error.

What is pg_database_owner in Postgres

A reference for which Postgres DDL operations rewrite the whole table (and take heavy locks) versus which ones are metadata-only, plus how to test it yourself before you run it in production.

Which Postgres Operation causes a table rewrite

A practical rundown of the Postgres Row-Level Security traps that quietly break performance or leak data, with the fix for each.

Postgres Row-Level Security Footguns

A walk through the three ways to roll back changes in Postgres: transactions and SAVEPOINT, Point-in-Time Recovery, and compensating DML, and when each one fits.

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

The limitations and gotchas of gh-ost for online MySQL schema changes, and when to reach for something else instead.

gh-ost Limitations You Need to Know Before Production

PostgreSQL best practices for application developers: connection naming, timeouts, online migrations, role separation, and UPSERT for reliable production apps.

Postgres best practices I wish every app developer knew

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

Supabase and MongoDB take different paths to storing application data. This article compares them on data model, architecture, performance, pricing, and licensing to help you decide which one fits.

Supabase vs. MongoDB: a Complete Comparison in 2026

DataGrip is a SQL IDE built for individual developers; Bytebase is a web platform built for teams that need review and governance. This post compares their database support, features, and pricing to help you decide which fits.

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


<HintBlock type="info">

PostgreSQL 19 Beta 1 [shipped on June 4, 2026](https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/). The feature set is now frozen for the release cycle, so every item below is confirmed in beta rather than drawn from a draft. Minor behavioral changes are still possible through the release candidates; we will track them here.

</HintBlock>

| Update History | Comment                                                                                                                     |
| -------------- | --------------------------------------------------------------------------------------------------------------------------- |
| 2026/06/08     | Updated for the [PostgreSQL 19 Beta 1 release](https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/).   |
| 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 finally 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 real production outages is gone. Autovacuum becomes parallel and, just as important, 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 a plan that is simply unacceptable in production. For years the workarounds all lived outside core: the [pg_hint_plan extension](https://github.com/ossc-db/pg_hint_plan), application-level `SET enable_*` flags, third-party plan-locking extensions. Each one has its own semantics and its own lifecycle to babysit.

This is not a theoretical pain. 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, and so on) 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`.

My verdict: this is plan stability without touching the application. One write to a stash takes effect across every session that runs the matching `queryId`, with no `pg_hint_plan` and no 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 don't reach for it across a whole workload. Use it as a scalpel, not a blanket.

## 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. So every team that needs it ends up writing its own extractor: a shell loop around `pg_dump --schema-only`, a hand-rolled catalog query inside a migration tool, or 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, and somebody has to keep up.

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.

My verdict: a stable in-core contract retires every team's homegrown extractor. Migration prep, CI/CD schema diffs, audit snapshots of role grants and database properties, embedded calls from schema-management tools, all of it stops parsing `pg_dump` text.

These functions complement `pg_dump` rather than replace it: single-object only, no dependency ordering, no indexes, triggers, or constraints. Permissions are scoped sensibly: `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.

My verdict: both items kill off a class of "schedule a window, hope nothing breaks" operations, and that hope-as-a-strategy approach is exactly what you want gone from a runbook.

One caveat. `REPACK CONCURRENTLY` deserves the same caution as any logical-decoding-backed feature: it consumes a replication slot, so a slow consumer or a stuck transaction will hold WAL. Pin `max_repack_replication_slots` to a reasonable upper bound and watch slot lag during long repacks. Online checksum toggling is the safer of the two, because the 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, so operators no longer need to flip the GUC in every new install.

My verdict: 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, and you'll find most contention surprises sitting in two or three hot tables.

### Recovery

Standby monitoring used to mean 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 then reconciling the results yourself. 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.

My verdict: the atomic snapshot is the part that matters. Previously, when alerts fired on "replica too far behind," telling real lag apart 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. What it has not reproduced is 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. A nasty surprise to discover at cutover.

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).

My verdict: zero-downtime upgrades and failover get meaningfully safer. The behavioral catch worth circling: sequences sync only when `REFRESH SEQUENCES` runs. They do not track continuously. So build the call into cutover runbooks, right before promoting the subscriber, or you'll re-discover the same primary-key violation the feature was meant to prevent.

Beta 1 pairs this with a second win for the same upgrade story: logical replication can now be enabled without a server restart. When `wal_level` is `replica`, the server promotes to logical decoding on demand, and a new read-only `effective_wal_level` reports what it is actually running. Standing up a temporary subscriber for a major-version upgrade no longer begins with a restart of the primary.

## 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, and high-concurrency workloads with foreign keys can hit it in days, not years. That asymmetry is what makes it dangerous.

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.

My verdict: the "vacuum or die" emergency for member exhaustion is over. The aggressive anti-wraparound vacuum that ran specifically against MultiXact member space is no longer needed, though routine vacuum still matters for disk reclamation. One operational note: upgrading to 19 rewrites the `pg_multixact` SLRU files via `pg_upgrade` automatically, so size the upgrade window accordingly on clusters with large multixact histories.

## Vacuum

Two long-standing complaints land together. Autovacuum can finally use parallel workers, and 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. About time.

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. You were left guessing.

My verdict: faster autovacuum on heavily-indexed tables, and for once a feedback loop to verify it actually ran the way you expected. 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 before assuming you got the speedup.

The 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. It 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. That distinction is the whole point.

The rest of the list is the kind of steady, hard-won progress that keeps PostgreSQL ahead in production. Vacuum and MultiXact are really 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 two 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. So the open question for 19: is this the release where the duct tape finally starts to come off, or just a sturdier roll of it?

## 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)


The
Bytebase Blog

Explore the standard for database development

Solutions & Platform

Comparisons

Legal

Resources

Company