Postgres

PlanetScale Postgres

Generic Postgres

Operations and Architecture

PlanetScale-Specific

Backup and Recovery

FUNDAMENTAL RULE: Backups are useless until you've successfully tested recovery.

Logical Backups (pg_dump)

Exports as SQL or custom format; portable across PG versions and architectures. Formats: -Fp (plain SQL), -Fc (custom compressed, selective restore), -Fd (directory, parallel with -j), -Ft (tar, avoid). Use -Fd -j 4 for large DBs. Restore: pg_restore -d dbname file.dump; add -j for parallel restore. Selective table restore: pg_restore -t tablename. Slow for large DBs; RPO = backup frequency (typically 24h).

Physical Backups (pg_basebackup)

Copies raw PGDATA; same major version and platform required; cross-architecture works if same endianness (e.g., x86_64 ↔ ARM64). Faster for large clusters; includes all databases. Flags: -Ft -z -P for compressed tar with progress. Manual alternative: pg_backup_start() → copy PGDATA → pg_backup_stop() (complex; must write returned backup_label).

PITR (Point-in-Time Recovery)

Requires base backup + continuous WAL archiving. Restores to any timestamp, transaction, or named restore point. Without PITR: restore only to backup time (potentially lose hours). With PITR: RPO = minutes. archive_command must return 0 ONLY when file is safely stored—premature 0 = data loss risk. wal_level must be replica or logical (not minimal).

WAL Archiving

archive_mode=on, archive_command='test ! -f /archive/%f && cp %p /archive/%f'. Test archive command as postgres user (not root) since permission issues are common. Monitor pg_stat_archiver for failed_count, last_archived_time. Archive failures prevent WAL recycling → disk fills.

Tool Comparison

RPO/RTO

Logical only: RPO = backup interval (hours); RTO = hours. PITR: RPO = minutes; RTO = hours. Synchronous replication: RPO = 0; RTO = seconds to minutes (failover).

Operational Rules

• Verify integrity with pg_verifybackup (PG 13+)
• Test recovery / PITR regularly
• Take backups from standby to avoid impacting primary
• Retention: 7 daily, 4 weekly, 12 monthly
• Monitor archive growth and backup age
• Never assume backups work without testing

Index Optimization

Identify Unused Indexes

Query to find unused indexes:

-- indexes with 0 scans (check pg_stat_reset / pg_postmaster_start_time first)
SELECT
   s.schemaname,
   s.relname AS table_name,
   s.indexrelname AS index_name,
   pg_size_pretty(pg_relation_size(s.indexrelid)) AS index_size
 FROM pg_catalog.pg_stat_user_indexes s
 JOIN pg_catalog.pg_index i ON s.indexrelid = i.indexrelid
 WHERE s.idx_scan = 0
   AND 0 <> ALL (i.indkey)       -- exclude expression indexes
   AND NOT i.indisunique          -- exclude UNIQUE indexes
   AND NOT EXISTS (               -- exclude constraint-backing indexes
     SELECT 1 FROM pg_catalog.pg_constraint c
     WHERE c.conindid = s.indexrelid
   )
 ORDER BY pg_relation_size(s.indexrelid) DESC;

Indexes Per Table Guidelines

• < 5: Normal
• 5-10: Monitor (Verify necessity)
• > 10: Audit required (High write overhead)

SELECT relname AS table, count(*) as index_count
FROM pg_stat_user_indexes
GROUP BY relname
ORDER BY count(*) DESC;

Identify Unused Indexes

Indexes with identical definitions (after normalizing names) on the same table are duplicates:

SELECT
  schemaname || '.' || tablename AS table,
  array_agg(indexname) AS duplicate_indexes,
  pg_size_pretty(sum(pg_relation_size((schemaname || '.' || indexname)::regclass))) AS total_size
FROM pg_indexes
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
GROUP BY schemaname, tablename,
  regexp_replace(indexdef, 'INDEX \S+ ON ', 'INDEX ON ')
HAVING count(*) > 1;

Always confirm with a human before dropping or removing any indexes identified by the queries above. Even indexes with 0 scans may be needed for infrequent but critical queries, and stats may have been reset recently.

Per-table Index Count Guidelines

Indexing Best Practices

Core Rules

1. Always index foreign key columns — PostgreSQL does not auto-create these 2. Index columns in WHERE, JOIN, and ORDER BY clauses 3. Don't over-index — each index slows writes and uses storage 4. Verify with EXPLAIN ANALYZE — confirm indexes are actually used

Composite Indexes

Put equality columns first, then range/sort columns:

-- WHERE status = 'active' AND created_at > '2026-01-01'
CREATE INDEX order_status_created_idx ON order (status, created_at);

A composite index on (a, b) supports queries on a + b and a alone, but not b alone.

Partial Indexes

Reduce index size by filtering to common query patterns. Only use if index size is problematic but the index is needed for performance.

CREATE INDEX order_active_idx ON order (customer_id)
  WHERE status = 'active';

Covering Indexes

Consider creating covering indexes for commonly executed query patterns that return only 1 or a small number of columns.

Index Types

CREATE INDEX metadata_idx ON order USING GIN (metadata);       -- JSONB
CREATE INDEX event_created_idx ON event USING BRIN (created_at); -- time-series

Guidelines

• Name indexes consistently: {table}_{column}_idx
• Review for unused indexes periodically
• Always confirm with a human before removing or dropping any indexes — even unused ones may serve a purpose not reflected in recent stats
• Use partial indexes for frequently filtered subsets
• Use covering indexes on hot read paths

Memory Architecture and OOM Prevention

Memory Areas

• Shared memory: shared_buffers — main data cache, all processes, requires restart to change.
• Private per backend: work_mem (sorts/hashes/joins, per-operation); maintenance_work_mem (VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY); temp_buffers (8MB default).
• Planner hint only: effective_cache_size is NOT allocated — set to ~50–75% of total RAM.
• Hash multiplier: hash_mem_multiplier (default 2.0) means hash ops use up to 2× work_mem.

Memory Multiplication Danger

Maximum potential: work_mem × operations_per_query × (parallel_workers + 1) × connections (leader participates by default via parallel_leader_participation = on; hash operations use up to hash_mem_multiplier × work_mem, default 2.0). Example: 128MB work_mem, 3 ops (2 sorts + 1 hash join), 2 parallel workers, 100 connections → 2 sorts at 128MB = 256MB, 1 hash join at 128MB × 2.0 = 256MB, per process = 512MB, × 3 processes (2 workers + leader) = 1536MB/query, × 100 connections = ~150GB worst case. This case is rare. Not all queries hit limits at once, but high concurrency + large datasets approach it. This is a common cause of OOM in containerized/Kubernetes deployments. Plan capacity with a 1.5–2× safety margin.

OS Page Cache (Double Buffering)

Data exists in both shared_buffers and OS page cache. A miss in shared_buffers can still hit OS cache (avoiding disk I/O). Extremely large shared_buffers can hurt performance: less OS cache, slower startup, heavier checkpoints. Optimal split depends on workload (OLTP vs OLAP).

OOM Prevention

• Implement connection pooling to reduce total backend count.
• Reduce work_mem globally; use per-session overrides for heavy queries only.
• Lower max_parallel_workers_per_gather in high-concurrency systems.
• Set statement_timeout to kill runaway queries.
• Monitor: dmesg -T | grep "killed process" and temp_blks_written in pg_stat_statements.

Operational Rules

• Tune per-session first, global last.
• Suspect OOM when memory spikes during high concurrency, dashboards, or large batch jobs.
• Increase memory only after confirming spill behavior (temp_blks_written > 0).
• maintenance_work_mem can be set much higher (1–2GB) — fewer processes use it. Cap autovacuum with autovacuum_work_mem to avoid autovacuum_max_workers × maintenance_work_mem memory spikes.
• shared_buffers change requires full restart; work_mem is per-session changeable.

Monitoring

Essential Views

• pg_stat_activity: First stop when something is wrong — running queries, states, wait events, locks.
• pg_stat_statements: Execution stats for all SQL. Requires shared_preload_libraries = 'pg_stat_statements' and CREATE EXTENSION pg_stat_statements.
• pg_stat_database: Cache hit ratio, temp files, deadlocks, connections per database.
• pg_stat_user_tables: seq_scan vs idx_scan, dead tuples, last vacuum/analyze times.
• pg_stat_user_indexes: Find unused indexes (idx_scan = 0 with large size).
• pg_stat_bgwriter: buffers_clean, maxwritten_clean, buffers_alloc. Pre-PG 17 also had buffers_checkpoint, buffers_backend (high = backends bypassing bgwriter). PG 17+ moved checkpoint stats to pg_stat_checkpointer.
• pg_stat_checkpointer (PG 17+): Checkpoint frequency (num_timed, num_requested), write/sync time.

Key Queries

-- Slow queries (with cache hit ratio)
SELECT query, calls, mean_exec_time,
  100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS cache_hit_pct
FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;

-- Connection counts / states
SELECT state, count(*) FROM pg_stat_activity GROUP BY state;

-- Dead tuples (vacuum candidates)
SELECT relname, n_dead_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;
-- last_autovacuum = <null> means autovacuum has not run on this table

Blocking: use pg_blocking_pids(pid) with pg_stat_activity to find blocked and blocking sessions.

Logging — First Line of Defense

PostgreSQL is extremely vocal about problems. Always check logs first: tail -f /var/log/postgresql/postgresql-*.log.

Key settings: log_min_duration_statement (OLTP: 1–3s, analytics: 30–60s, dev: 100–500ms). Enable log_checkpoints=on, log_connections=on, log_disconnections=on, log_lock_waits=on, log_temp_files=0. Use CSV log format for pgBadger analysis; pgBadger generates HTML reports with query stats and performance graphs.

pg_activity

Interactive top-like tool (pip install pg_activity). Run on DB host for OS metrics alongside PG metrics. Combines pg_stat_activity with CPU/memory/I/O context.

Host Metrics — Critical

PostgreSQL cannot report these. Monitor them yourself:

• CPU: Steal time >10% in VMs bad; load average > core count; context switches >100k/sec.
• Memory: Any swap = performance degradation. Check dmesg for OOM kills.
• Disk I/O: iostat -x — %util=100% means saturated; await >10ms = high latency.
• Disk space: >90% critical (VACUUM fails, writes fail). Check inode usage too.
• Network: Packet loss >0% = problems; high retransmits = instability.

Statistics Management

Stats accumulate since last reset or restart; check stats_reset timestamp. pg_stat_statements_reset() clears query stats; pg_stat_reset() clears database stats. Reset after major maintenance, config changes, or perf testing — not routinely. Prefer snapshotting stats to external monitoring (Prometheus, Datadog) over resetting. Always confirm with a human before resetting statistics — resetting destroys historical performance baselines and can make it harder to identify unused indexes or regressions.

MVCC Transactions and Concurrency

Transaction Isolation Levels

• READ UNCOMMITTED — treated as READ COMMITTED in PostgreSQL; no dirty reads ever.
• READ COMMITTED (default): new snapshot per statement; can see different data within same tx.
• REPEATABLE READ: snapshot at first query; can cause serialization errors on write conflicts.
• SERIALIZABLE: strongest; transactions appear serial; requires retry logic in app code.

Readers never block writers; writers never block readers (only writer-writer conflicts on same row). No lock escalation — row locks never degrade to table locks.

XID Wraparound

32-bit transaction IDs wrap at ~2 billion (2^31). VACUUM FREEZE replaces old XIDs with FrozenXID (value 2, always visible). Without freeze: after wraparound, old rows appear "in the future" and become invisible. Data physically exists but is invisible to all queries — looks like total data loss. PostgreSQL emergency shutdown at 2B XIDs to prevent this. XID wraparound should be avoided at all cost.

Warning messages start at ~1.4B XIDs; shutdown at 2B. Recovery requires single-user mode VACUUM — can take hours to days on large DBs. Never disable autovacuum — it's your protection against wraparound.

XID Age Monitoring

SELECT datname, age(datfrozenxid),
  ROUND(100.0 * age(datfrozenxid) / 2147483648, 2) AS pct
FROM pg_database ORDER BY age(datfrozenxid) DESC;

Long Transaction Impact

A single long-running transaction blocks VACUUM from removing dead tuples across the entire database. Causes table bloat, increased disk, slower queries, cache pollution. idle_in_transaction connections are the #1 operational MVCC issue. Set idle_in_transaction_session_timeout (30s–5min). Dead tuples waste I/O on seq scans and cause useless heap lookups from indexes.

Serialization Errors

Apps must handle "could not serialize access" with retry logic. More common in REPEATABLE READ and SERIALIZABLE. Smaller, faster transactions reduce conflict frequency.

MVCC and VACUUM

MVCC

Every UPDATE creates a new tuple and marks the old one dead; DELETE marks tuples dead. Dead tuples accumulate until VACUUM reclaims space. Each transaction gets a 32-bit XID (2^32 ≈ 4B values, but modular comparison means the effective danger zone is 2^31 ≈ 2B). VACUUM must freeze old XIDs to prevent wraparound.

VACUUM vs VACUUM FULL

VACUUM is non-blocking (ShareUpdateExclusive lock) and marks dead space reusable. VACUUM FULL rewrites the table and requires an AccessExclusive lock — use only as a last resort. For online bloat reduction prefer pg_squeeze or pg_repack.

Autovacuum Tuning

Triggers when dead tuples > Min(autovacuum_vacuum_max_threshold, autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor * reltuples). autovacuum_vacuum_max_threshold defaults to 100M (PG 18+), capping the threshold for very large tables. Also triggers on inserts exceeding autovacuum_vacuum_insert_threshold + autovacuum_vacuum_insert_scale_factor * reltuples * pct_not_frozen (ensures insert-only tables get frozen; PG 13+). For large/hot tables, set per-table overrides:

• autovacuum_vacuum_scale_factor — default 0.2; lower to 0.01–0.05 for large tables.
• autovacuum_vacuum_cost_delay — default 2 ms; set to 0 on fast storage.
• autovacuum_vacuum_cost_limit — default -1 (uses vacuum_cost_limit, effectively 200); raise to 1000–2000 on fast storage.
• autovacuum_freeze_max_age — default 200M; triggers anti-wraparound vacuum.
• vacuum_failsafe_age — default 1.6B; last-resort mode (PG 14+) that disables throttling and skips index vacuuming when wraparound is imminent.

Key Monitoring Queries

Dead tuples: SELECT relname, n_dead_tup, last_autovacuum FROM pg_stat_user_tables ORDER BY n_dead_tup DESC;

XID age: SELECT datname, age(datfrozenxid) AS xid_age FROM pg_database ORDER BY xid_age DESC;

Long transactions: SELECT pid, state, now() - xact_start AS tx_age FROM pg_stat_activity WHERE xact_start IS NOT NULL ORDER BY xact_start;

Best Practices

• Keep transactions short; set idle_in_transaction_session_timeout (30s–5min).
• Alert when age(datfrozenxid) exceeds 40–50% of wraparound (~800M–1B).
• Tune autovacuum per-table for write-heavy tables; don't change global defaults first.
• Fix application transaction scope before adjusting vacuum parameters.
• Never disable autovacuum globally.

Optimization Checklist

When optimizing performance, check the following:

• Look for unused indexes (0 scans; exclude unique/primary indexes and verify stats age first)
• Look for duplicate indexes
• Archive audit/log tables >10GB
• Review tables >500GB for partitioning (>100GB for time-series/logs)
• Verify all extensions are supported
• Check for circular foreign key dependencies
• Consider alternatives to UUID primary keys for large tables
• Configure connection pooling for OLTP workloads
• Always confirm with a human before removing any indexes, dropping partitions, archiving tables, or performing other destructive actions

Table Partitioning

Plan partitioning upfront for tables expected to grow large. Retrofitting later requires a migration.

When to Partition

Partitioning benefits maintenance (vacuum, index builds) and data retention more than pure query speed.

Use the lower thresholds for append-heavy, time-ordered data with retention needs (logs, events, audit trails, metrics).

Range Partitioning (Most Common)

-- EXAMPLE
CREATE TABLE event (
  id BIGINT GENERATED ALWAYS AS IDENTITY,
  event_type TEXT NOT NULL,
  payload JSONB,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  PRIMARY KEY (id, created_at) -- Partition key MUST be part of PK
) PARTITION BY RANGE (created_at);

CREATE TABLE event_2026_01 PARTITION OF event
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE event_2026_02 PARTITION OF event
  FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

List Partitioning

Useful for partitioning by region, tenant, or category:

-- EXAMPLE
CREATE TABLE order (
  id BIGINT GENERATED ALWAYS AS IDENTITY,
  region TEXT NOT NULL,
  total NUMERIC(10,2),
  PRIMARY KEY (id, region) -- Partition key MUST be part of PK
) PARTITION BY LIST (region);

CREATE TABLE order_us PARTITION OF order FOR VALUES IN ('us');
CREATE TABLE order_eu PARTITION OF order FOR VALUES IN ('eu');
CREATE TABLE order_default PARTITION OF order DEFAULT;  -- catches unmatched values

Partition Management

• Use pg_partman (extension) to automate partition creation and cleanup.
• Use DETACH PARTITION to remove a partition while retaining it as a standalone table (e.g., for archiving).
• Use DETACH PARTITION ... CONCURRENTLY (PG 14+) to avoid ACCESS EXCLUSIVE locks on the parent table.
• Drop old partitions for data retention instead of DELETE to avoid vacuum overhead and bloat.
• Create future partitions ahead of time to avoid insert failures.
• Always confirm with a human before detaching or dropping partitions. These are destructive actions — detaching removes data from the partitioned table, and dropping permanently deletes the data.

-- DESTRUCTIVE: confirm with a human before executing
ALTER TABLE event DETACH PARTITION event_2025_01 CONCURRENTLY;
DROP TABLE event_2025_01;

Guidelines & Limitations

• Primary Keys: Partition key columns MUST be included in the PRIMARY KEY and any UNIQUE constraints.
• Global Uniqueness: Global unique constraints on non-partition columns are NOT supported.
• Indexes: Indexes defined on the parent are automatically created on all partitions (and future ones).
• Pruning: Ensure queries filter by the partition key to enable "partition pruning" (skipping unrelated partitions).

Process Architecture

PostgreSQL uses a multi-process model, not multi-threaded: one OS process per client connection. The postmaster is the parent; it spawns backend processes per connection. Each backend has some private memory (work_mem, temp buffers). 1000 connections = 1000 processes (~5–10MB base + query memory each). There is also a large buffer shared amongst all.

Auxiliary Processes

WAL Writer, Background Writer, Checkpointer, Autovacuum Launcher/Workers, Archiver, WAL Summarizer (PG 17+). These run alongside backends and are not spawned per connection.

Memory Risk

work_mem is per-operation, not per-query. Estimate: work_mem × operations_per_query × parallel_workers × connections can grow very large at high concurrency. Scale connections and parallelism before raising work_mem.

Connection Pooling (Critical)

Each connection = OS process (fork overhead, context switching, memory). PgBouncer can multiplex many app connections to fewer DB connections. Typical: 1000 app connections → pooler → 20–50 backends. Implement pooling before raising max_connections; max_connections requires a full restart to change (default 100). Note: superuser_reserved_connections (default 3) reserves slots for emergency superuser access, so non-superusers are rejected before max_connections is fully reached.

Monitoring

SELECT state, count(*) FROM pg_stat_activity WHERE backend_type = 'client backend' GROUP BY state;

-- Show used and free connection slots
SELECT count(*) AS used, max(max_conn) - count(*) AS free
FROM pg_stat_activity, (SELECT setting::int AS max_conn FROM pg_settings WHERE name = 'max_connections') s
WHERE backend_type = 'client backend';

Use pg_activity for interactive top-like monitoring. Alert at 80% connection usage, critical at 95%. Count by state to find idle-in-transaction leaks — these hold locks and block VACUUM from reclaiming dead tuples.

Common Problems

Prefer pooling + conservative max_connections over raising limits reactively.

Query Insights via pscale CLI

Analyze slow queries and missing indexes using pscale api. Endpoints may change—see https://planetscale.com/docs/api/reference/getting-started-with-planetscale-api for current API docs.

Using pscale api

The pscale api command makes authenticated API calls using your current login or service token (see ps-cli-commands.md for auth setup). No need to manage auth headers manually.

pscale api "<endpoint>" [--method POST] [--field key=value] [--org <org>]

Query Patterns Reports

# Create a new report
pscale api "organizations/{org}/databases/{db}/branches/{branch}/query-patterns-reports" \
  --method POST --org my-org

# Check status (poll until state=complete)
pscale api "organizations/{org}/databases/{db}/branches/{branch}/query-patterns-reports/{id}/status"

# Download completed report
pscale api "organizations/{org}/databases/{db}/branches/{branch}/query-patterns-reports/{id}"

# List all reports
pscale api "organizations/{org}/databases/{db}/branches/{branch}/query-patterns-reports"

Schema Analysis

# Get branch schema
pscale api "organizations/{org}/databases/{db}/branches/{branch}/schema"

# Lint schema for issues
pscale api "organizations/{org}/databases/{db}/branches/{branch}/schema/lint"

What to Look For

pscale CLI Commands

Full CLI reference: https://planetscale.com/docs/cli. Use pscale <command> --help for subcommands and flags.

Authentication

pscale auth login                    # Opens browser
pscale auth logout
pscale org list
pscale org switch <name>

Service Token (CI/CD)

# Create and configure
pscale service-token create
pscale service-token add-access <id> read_branch --database <db>
# Use in CI/CD
export PLANETSCALE_SERVICE_TOKEN_ID="<id>"
export PLANETSCALE_SERVICE_TOKEN="<token>"

Core Commands

# Databases
pscale database list
pscale database create <name>

# Branches
pscale branch list <db>
pscale branch create <db> <branch> [--from <parent>]
pscale branch delete <db> <branch>    # DESTRUCTIVE — always confirm with a human first
pscale branch schema <db> <branch>

# Deploy requests (schema changes) — Vitess only
pscale deploy-request create <db> <branch>
pscale deploy-request list <db>
pscale deploy-request deploy <db> <number>

# Connect
pscale shell <db> <branch>           # Opens psql (Postgres) or mysql (Vitess)
pscale connect <db> <branch>         # Proxy for GUI tools (secure tunnel) — Vitess only

# Credentials
pscale role create <db> <branch> <name>      # Postgres
pscale password create <db> <branch> <name>  # Vitess

# Other
pscale ping              # Check latency to regions
pscale region list       # Available regions
pscale backup list <db> <branch>
pscale backup create <db> <branch>

Useful Flags

--format json    # Output as JSON (also: csv, human)
--org <name>     # Specify organization
--debug          # Debug output

For API calls via CLI, see ps-cli-api-insights.md.

Connection Pooling with PgBouncer

PlanetScale provides PgBouncer for connection pooling. Connect on port 6432 instead of 5432.

When to Use PgBouncer (Port 6432)

All OLTP application workloads: web apps, APIs, high-concurrency read/write operations.

When to Use Direct Connections (Port 5432)

• Schema changes (DDL)
• Analytics, reporting, batch processing
• Session-specific features (temp tables, session variables)
• ETL, data streaming, pg_dump
• Long-running admin transactions

PgBouncer Types

PlanetScale offers three PgBouncer options. All use port 6432.

• Local PgBouncer — use same credentials as direct, just change port to 6432. Always routes to primary regardless of username.
• Dedicated Primary — runs off-server for improved HA. Use for production OLTP write traffic.
• Dedicated Replica — runs off-server for read-heavy workloads. Supports AZ affinity to prefer same-zone replicas. Multiple can be created for capacity or per-app isolation.

To connect to a dedicated PgBouncer, append |pgbouncer-name to the username (e.g., postgres.xxx|write-pool or postgres.xxx|read-bouncer).

Transaction Pooling Limitations

PlanetScale PgBouncer uses transaction pooling mode. These features are unavailable:

• Prepared statements that persist across transactions
• Temporary tables
• LISTEN/NOTIFY
• Session-level advisory locks
• SET commands persisting beyond a transaction

Recommended Patterns

• Size pools from observed concurrency, query memory behavior, and connection limits.
• Keep pooled app traffic on 6432 and reserve direct connections for DDL/admin/long-running jobs.

Avoid Patterns

• Avoid setting pool size with only CPU_cores * N while ignoring query-memory amplification.
• Avoid running session-dependent workflows through transaction pooling.

Connecting

# Local PgBouncer (same credentials, port 6432)
psql 'host=xxx.horizon.psdb.cloud port=6432 user=postgres.xxx password=pscale_pw_xxx dbname=mydb sslnegotiation=direct sslmode=verify-full sslrootcert=system'

# Dedicated primary PgBouncer (append |pgbouncer-name to user)
psql 'host=xxx.horizon.psdb.cloud port=6432 user=postgres.xxx|write-pool password=pscale_pw_xxx dbname=mydb sslnegotiation=direct sslmode=verify-full sslrootcert=system'

# Dedicated replica PgBouncer (append |pgbouncer-name to user)
psql 'host=xxx.horizon.psdb.cloud port=6432 user=postgres.xxx|read-bouncer password=pscale_pw_xxx dbname=mydb sslnegotiation=direct sslmode=verify-full sslrootcert=system'

Docs: https://planetscale.com/docs/postgres/connecting/pgbouncer

PlanetScale Postgres Connections

Postgres docs: https://planetscale.com/docs/postgres/connecting

Credentials (roles) are branch-specific and cannot be recovered after creation.

Connection String

postgresql://<user>:<password>@<host>.horizon.psdb.cloud:5432/<database>?sslmode=verify-full&sslrootcert=system&sslnegotiation=direct

Use port 6432 for PgBouncer (applications/OLTP). Use port 5432 for DDL, admin tasks, and migrations.

Troubleshooting

Best practices:

• Use the PlanetScale Postgres metrics page to monitor direct and PgBouncer connections
• Route OLTP traffic to port 6432 and reserve 5432 for admin/migrations.
• Avoid raising max_connections reactively instead of pooling.

PostgreSQL Extensions on PlanetScale

Only use PlanetScale-supported extensions. For the complete and up-to-date list of available extensions, see: https://planetscale.com/docs/postgres/extensions

Do not rely on hard-coded extension lists — always check the documentation above for current availability.

Enabling Extensions

Some extensions must first be enabled in the PlanetScale Dashboard (Clusters > Extensions) before they can be created in SQL. This often requires a database restart.

Once enabled in the dashboard, create the extension in SQL:

CREATE EXTENSION IF NOT EXISTS <extension_name>;

Recommended Patterns

• Always check the PlanetScale extensions docs before assuming an extension is available.
• Verify extension availability in PlanetScale configuration and docs before schema design depends on it.
• Enable pg_stat_statements early for baseline query telemetry.

PlanetScale Insights

Fetch current documentation first

Prefer retrieval over pre-training knowledge. Docs: https://planetscale.com/docs

MCP Server (Preferred)

When the PlanetScale MCP server is configured in your environment, prefer it over CLI. Key tools:

• planetscale_get_branch_schema — Get schema for a branch
• planetscale_execute_read_query — Run SELECT, SHOW, DESCRIBE, EXPLAIN
• planetscale_get_insights — Query performance insights
• planetscale_list_schema_recommendations — Index and schema suggestions
• planetscale_search_documentation — Search PlanetScale docs

MCP setup: https://planetscale.com/docs/connect/mcp

The MCP server is the ideal way to interact with insights from an AI agent. If not installed, prompt the user to install it to make the agent more effective.

Query Insights (CLI)

Generating reports via CLI is a multi-step process (create → wait → download).

See ps-cli-api-insights.md for how to use.

What to look for:

• High rows_read / rows_returned ratio → missing index
• High total_time_s → optimization target

Insights UI (Dashboard)

In the PlanetScale dashboard, select your database and click Insights.

• Filtering — Pick a branch, choose primary or replica, and scroll through the last 7 days. Click-and-drag on graphs to zoom into a time window.
• Graphs — Four tabs: Query latency (p50/p95/p99/p99.9), Queries per second, Rows read/s, and Rows written/s.
• Queries table — All queries in the selected timeframe, normalized into patterns. Sortable and filterable by SQL, schema, table, latency, index usage, and more. Customizable columns (count, total time, latency percentiles, rows read/returned/affected, CPU/IO time, cache hit ratio, etc.). Enable sparklines for inline trend graphs. Orange icons flag full table scans.
• Query deep dive — Click any query to see per-pattern graphs, summary stats, index usage breakdown, and a table of notable executions (>1 s, >10k rows read, or errors). Use "Summarize query" for an LLM-generated plain-English description.
• Anomalies tab — Flags periods with elevated slow-running queries and surfaces the responsible patterns.
• Errors tab — Surfaces queries that produced errors.
• pginsights settings — pginsights.raw_queries enables full query text collection for notable queries; pginsights.normalize_schema_names groups identical patterns across schemas (useful for schema-per-tenant designs). Both configurable in the Extensions tab on the Clusters page.

More: PlanetScale Insights docs

Optimization Checklist

• Remove unused indexes (0 scans)
• Remove duplicate indexes
• Archive audit/log tables >10 GB
• Review tables >100 GB for partitioning

Always confirm with a human before removing indexes, dropping tables/partitions, or archiving data. These are destructive actions that cannot be easily undone.

More: optimization-checklist.md

SQL Query Patterns

Query Structure

SELECT specific columns — avoids fetching unnecessary data and enables covering indexes:

-- Bad:
SELECT * FROM user WHERE status = 'active';
-- Good:
SELECT id, name, email FROM user WHERE status = 'active';

Subqueries → JOINs — correlated subqueries re-execute per row:

-- Bad
SELECT id, (SELECT COUNT(*) FROM order WHERE order.user_id = user.id) FROM user;
-- Good
SELECT u.id, COUNT(o.id) FROM user u LEFT JOIN order o ON o.user_id = u.id GROUP BY u.id;

Always LIMIT unbounded queries — prevent runaway result sets:

SELECT id, message FROM log WHERE level = 'error' ORDER BY created_at DESC LIMIT 100;

Avoid functions on indexed columns (SARGable) — functions prevent index usage unless a functional index exists:

-- Bad: Full table scan
SELECT * FROM user WHERE date_trunc('day', created_at) = '2023-01-01';
-- Good: Index scan
SELECT * FROM user WHERE created_at >= '2023-01-01' AND created_at < '2023-01-02';

N+1 Detection

Queries inside loops → batch with ANY/IN:

# Bad
for uid in user_ids:
    cursor.execute("SELECT name FROM user WHERE id = %s", (uid,))
# Good (Postgres specific)
cursor.execute("SELECT id, name FROM user WHERE id = ANY(%s)", (list(user_ids),))
# Good (Standard SQL)
# cursor.execute("SELECT id, name FROM user WHERE id IN %s", (tuple(user_ids),))

ORM lazy loading → eager loading:

# Bad: N+1 — each iteration fires a query
for user in User.query.all():
    print(user.posts)
# Good
users = User.query.options(joinedload(User.posts)).all()

Query Rewrites

UNION → UNION ALL — skip deduplication when duplicates are impossible or acceptable.

IN subquery → EXISTS — EXISTS short-circuits on first match:

SELECT id, name FROM user u
WHERE EXISTS (SELECT 1 FROM order o WHERE o.user_id = u.id AND o.total > 100);

OFFSET → cursor pagination — OFFSET scans and discards rows, degrading at depth:

-- Bad: OFFSET 10000 scans 10020 rows
SELECT id, title FROM article ORDER BY created_at DESC LIMIT 20 OFFSET 10000;
-- Good: cursor-based (requires index on (created_at DESC, id DESC))
SELECT id, title FROM article
WHERE (created_at, id) < ('2025-06-15T12:00:00Z', 987654)
ORDER BY created_at DESC, id DESC LIMIT 20;

Replication

Streaming Replication for followers

Use physical (byte-for-byte) replication via WAL stream from primary to standbys. Standbys are read-only (hot standby); same major PG version and architecture required (same minor recommended). Without replication slots, the primary may recycle WAL before the standby receives it → standby needs full resync via pg_basebackup. Use replication slots to guarantee WAL retention for specific standbys.

Replication Slots

Postgres supports Physical slots (streaming) and logical slots (logical replication). Slots prevent WAL deletion even if standby is offline — can exhaust pg_wal/ disk. Use max_slot_wal_keep_size to cap retained WAL per slot. Use idle_replication_slot_timeout (PG 17+) to auto-invalidate idle slots. wal_keep_size is a simpler alternative to slots for WAL retention. Drop inactive slots immediately to prevent disk exhaustion.

Slot lag (MB behind): SELECT slot_name, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)/1024/1024 AS mb_behind FROM pg_replication_slots;

Drop inactive slot: SELECT pg_drop_replication_slot('slot_name');

Always confirm with a human before dropping replication slots. Dropping an active or needed slot can cause downstream issues.

Synchronous Commit Levels

Configure with synchronous_standby_names. Use ANY N for quorum or FIRST N for priority-based sync.

Quorum and Failure

FIRST 2 (s1, s2, s3) is priority-based: waits for the 2 highest-priority connected standbys (s1+s2; s3 takes over only if one disconnects). ANY 2 (s1, s2, s3) is quorum-based: waits for any 2. With either, if only 1 is healthy, commits hang. Provision at least N+1 standbys: need 2 confirmations → provision 3. PostgreSQL never commits unless required standbys confirm — no inconsistency, but clients may timeout.

Failover

pg_ctl promote or SELECT pg_promote() (SQL function, PG 12+) converts standby to primary. One-way: promoted standby cannot rejoin as standby without rebuild. pg_rewind can resync old primary to new primary (requires wal_log_hints=on or data checksums) — faster than full rebuild. After promotion: update connection strings, rebuild old primary as standby, reconfigure other standbys.

Monitoring

On the primary, query pg_stat_replication for each connected standby's state (streaming = healthy, catchup = behind), sync_state (sync/async), and LSN positions (sent_lsn, write_lsn, flush_lsn, replay_lsn) to compute lag. On standbys, pg_stat_wal_receiver shows the receiver process status and flushed_lsn; compare pg_last_wal_receive_lsn() vs pg_last_wal_replay_lsn() for local replay lag.

Replication lag (MB): SELECT application_name, pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)/1024/1024 AS lag_mb FROM pg_stat_replication;

Enable wal_compression (pglz, lz4, or zstd) to compress full page images in WAL (not all WAL data) — reduces WAL size for bandwidth-limited replication.

Schema Design

Primary Keys

Prefer BIGINT GENERATED ALWAYS AS IDENTITY. Avoid random UUIDs (UUIDv4) as primary keys; use uuidv7() when you need UUIDs.

CREATE TABLE user (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email TEXT NOT NULL UNIQUE
);

Random UUID PKs (v4) can cause index fragmentation; UUIDs are also larger (16 vs 8 bytes for BIGINT) and can slow joins.

Data Types

Prefer CHECK constraints over ENUM types — they're easier to modify:

CREATE TABLE order (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  status TEXT NOT NULL CHECK (status IN ('pending', 'shipped', 'delivered'))
);

Foreign Keys

• Always index FK columns (PostgreSQL does not auto-create these)
• Avoid circular FK dependencies
• Suggestion: use ON DELETE CASCADE or ON DELETE SET NULL explicitly

CREATE TABLE order (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  customer_id BIGINT NOT NULL REFERENCES customer(id) ON DELETE CASCADE
);
CREATE INDEX order_customer_id_idx ON order (customer_id);

Naming Conventions

• Tables: singular snake_case (user_account, order_item)
• Columns: singular snake_case (created_at, user_id)
• Indexes: {table}_{column}_idx
• Constraints: {table}_{column}_{type} (e.g., order_status_check)

General Guidelines

• Add NOT NULL to as many columns as possible
• Add created_at TIMESTAMPTZ DEFAULT NOW() to all tables
• Use BIGINT for all IDs and foreign keys, even on small tables
• Keep tables normalized; denormalize only for proven hot read paths

Storage Layout and Tablespaces

PGDATA Structure

• base/ — database files (one subdirectory per database, named by OID)
• global/ — cluster-wide shared catalogs (pg_database, pg_authid, pg_tablespace)
• pg_wal/ — WAL files
• pg_xact/ — transaction commit status

"Cluster" in PostgreSQL = single instance with one PGDATA, not an HA cluster. Each table/index = one or more files, split into 1GB segments. Tables have companion _fsm (free space map) and _vm (visibility map); indexes have _fsm only (no _vm), except hash indexes.

Visibility Map and Free Space Map

• _vm tracks all-visible pages — VACUUM skips these
• _fsm tracks free space per page — INSERT uses this to find pages with room
• Both are small files but critical for performance

TOAST

TOAST triggers when a row exceeds ~2KB. Large values are compressed and/or moved out-of-line to pg_toast.pg_toast_<oid> tables. Strategies: PLAIN (no TOAST), EXTENDED (compress+out-of-line, default for text/bytea), EXTERNAL (out-of-line, no compression — use for pre-compressed data), MAIN (compress, avoid out-of-line). TOAST tables bloat like regular tables — they need VACUUM. SELECT * fetches all TOAST columns; always SELECT only needed columns. Move large rarely-accessed columns to separate tables.

Fillfactor

Controls how full pages are packed (default 100%). Lower fillfactor (70–80%) leaves room for HOT (Heap-Only Tuple) updates, which avoid index entries and reduce bloat on UPDATE-heavy tables. Keep 100% for insert-only or read-mostly tables. ALTER TABLE t SET (fillfactor = 70);

Tablespaces

pg_default (base/), pg_global (global/) are built-in. Custom tablespaces: symbolic links in pg_tblspc/ to other filesystem locations. Use for separating hot data (SSD) from archives (HDD). Moving tablespaces requires exclusive lock on affected tables.

Disk Monitoring

• pg_database_size('dbname'), pg_total_relation_size('tablename'), pg_relation_size('tablename')
• Monitor disk usage: >80% = at risk; >90% = critical (VACUUM may fail if disk capacity is insufficient)
• Check inode usage (df -i) — can run out even with free space
• pg_wal/ suddenly large = check replication slots and archiving

WAL and Checkpoint Operations

WAL Fundamentals

Write-Ahead Logging: logs changes to pg_wal/ before modifying data files. WAL segments are 16MB (fixed at initdb). On COMMIT, PostgreSQL fsyncs WAL to disk and returns SUCCESS — data files are updated lazily. WAL records are written for all changes (including uncommitted transactions and rollbacks). Never disable `fsync` in production — power loss without fsync risks unrecoverable data loss.

wal_level: minimal (crash recovery only), replica (default; replication + archiving), logical (logical replication).

Dirty Pages and Checkpoints

A dirty page is modified in shared_buffers but not yet written to data files. A checkpoint flushes all dirty pages to disk and writes a checkpoint record to WAL; recovery only replays WAL since the last checkpoint.

• checkpoint_timeout (default 5 min) and max_wal_size (default 1GB) — checkpoint on whichever triggers first.
• checkpoint_completion_target=0.9 spreads I/O over 90% of the interval; avoid spikes.
• "Checkpoints are occurring too frequently" in logs → increase max_wal_size.
• Target: >90% of checkpoints should be time-based (num_timed in pg_stat_checkpointer), not size-based (num_requested). If num_requested/(num_timed+num_requested) > 10%, tune max_wal_size up.

WAL Disk Management

Replication slots prevent WAL deletion even when standbys are offline — they can fill disk. WAL archiving failures also block recycling. max_wal_size is a soft limit; WAL can grow beyond it under heavy load.

WAL size: SELECT count(*) AS files, pg_size_pretty(sum(size)) AS total FROM pg_ls_waldir();

Slot lag: SELECT slot_name, pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes FROM pg_replication_slots;

Checkpoint Monitoring

PG17+ moved checkpoint stats from pg_stat_bgwriter to pg_stat_checkpointer and renamed columns.

SELECT num_timed, num_requested, write_time, sync_time, buffers_written FROM pg_stat_checkpointer;

Backend-direct writes (formerly buffers_backend in pg_stat_bgwriter) are now tracked in pg_stat_io: SELECT writes FROM pg_stat_io WHERE backend_type = 'client backend' AND object = 'relation';

Crash Recovery

On crash, PostgreSQL replays WAL from the last checkpoint. Longer checkpoint intervals → more WAL to replay → longer recovery. Trade-off: frequent checkpoints (faster recovery, more I/O) vs infrequent (less I/O, slower recovery). For most workloads, checkpoint_timeout=5min and max_wal_size tuned to keep checkpoints time-based is the right balance.