Česky na konci článku.

PostgreSQL performance tuning is often reduced to changing a few parameters in postgresql.conf.

That approach is dangerous.

A production database does not become faster simply because shared_buffers, work_mem or effective_cache_size look different. PostgreSQL performance is the result of the entire workload: SQL queries, execution plans, indexes, statistics, memory, I/O, WAL, autovacuum, connections and the underlying infrastructure.

The correct approach is simple:

Measure → Identify → Change → Validate.

The PostgreSQL documentation itself recommends using EXPLAIN and EXPLAIN ANALYZE to understand how queries are executed and how planner statistics influence their performance.

Start with the workload

Before changing configuration, establish what is actually happening.

A DBA should collect:

  • query latency
  • transaction throughput
  • CPU utilization
  • I/O utilization
  • active connections
  • lock activity
  • temporary file usage
  • WAL generation
  • checkpoint behavior
  • autovacuum activity

This creates a baseline against which every change can be evaluated.

Oracle follows the same fundamental philosophy: performance tuning should start with identifying the most significant bottleneck and comparing the system against a performance baseline.

Find the expensive SQL

One of the first places to investigate is the SQL workload.

pg_stat_statements can help identify queries consuming the most execution time and resources.

Then inspect individual queries using:

EXPLAIN (ANALYZE, BUFFERS)
SELECT ...
FROM orders
WHERE customer_id = 12345;

The important question isn’t simply:

„Is the query slow?“

It is:

„Why is PostgreSQL spending time executing it?“

The execution plan can reveal sequential scans, inefficient joins, excessive row estimates, sorting, temporary I/O and inefficient index usage.

Don’t create indexes blindly

Indexes can dramatically improve read performance.

But every index also has a cost.

Additional indexes mean:

  • more storage
  • additional write overhead
  • more WAL
  • additional maintenance
  • longer vacuum activity

A good DBA therefore asks whether the index actually solves a measurable problem.

The objective is not:

„More indexes.“

It is:

„The right access path for the workload.“

Autovacuum is part of performance engineering

Autovacuum is sometimes treated as background housekeeping.

In production PostgreSQL, that is a mistake.

Poor vacuum configuration can lead to:

  • table bloat
  • inefficient scans
  • increased storage consumption
  • transaction ID pressure
  • increased I/O
  • degraded query performance

PostgreSQL performance therefore has to be considered together with maintenance and transaction behavior.

Configuration comes later

Only after identifying the bottleneck should the DBA consider parameters such as:

  • shared_buffers
  • work_mem
  • effective_cache_size
  • maintenance_work_mem
  • max_wal_size
  • checkpoint settings
  • autovacuum parameters
  • connection limits

There are no universally correct values for these settings. The correct configuration depends on hardware, workload and concurrency. Current PostgreSQL guidance explicitly emphasizes understanding the workload and planner behavior rather than applying a generic configuration template.

PostgreSQL 18 makes this even more interesting

PostgreSQL 18 introduced several performance-related improvements, including skip-scan optimization for multicolumn indexes, enhanced EXPLAIN information and optimizer improvements that can help preserve plans across major upgrades.

For DBAs, this means that performance tuning isn’t a one-time configuration exercise.

It is an ongoing operational discipline.

The DBA performance loop

A mature production process looks like this:

1. Measure

Establish latency, throughput and resource baselines.

2. Diagnose

Find the actual bottleneck using query statistics, execution plans, waits and infrastructure metrics.

3. Change

Apply the smallest change capable of addressing the identified problem.

4. Validate

Measure the same workload again.

5. Document

Record the change, reason, impact and rollback procedure.

6. Monitor

Make sure the improvement remains valid as workload and data volume change.

This is the difference between configuration tweaking and database performance engineering.

2️⃣ Non-technical / SEO article — English

What Does a Senior Database Administrator Actually Do?

When companies think about databases, they often think about data.

A Senior Database Administrator thinks about something broader:

Can the business depend on that data being available, secure and fast when it is needed?

That is the real responsibility of a modern DBA.

A database administrator is more than a database operator

A senior DBA is responsible for the environment behind business applications.

That includes:

  • availability
  • performance
  • security
  • backup and recovery
  • disaster recovery
  • monitoring
  • capacity planning
  • upgrades
  • migrations
  • troubleshooting
  • automation

In a modern enterprise environment, database administration also overlaps with infrastructure, cloud, DevOps, security and application engineering.

Performance is a business problem

A slow database does not simply create a technical problem.

It can cause:

  • slow applications
  • frustrated employees
  • customer complaints
  • delayed transactions
  • missed business deadlines
  • increased infrastructure costs

This is why database performance tuning should focus on measurable business impact rather than simply changing configuration parameters.

A good DBA looks for the real bottleneck and proves that a change actually improved the system.

Reliability comes first

A production database should not depend on luck.

Senior database administrators design for failure.

That means considering:

What happens if a server fails?

What happens if storage becomes unavailable?

What happens if an application generates unexpected load?

How quickly can the database be recovered?

High availability, replication, backup and disaster recovery are therefore fundamental parts of modern database administration.

Automation changes the DBA role

Traditional database administration involved a large amount of repetitive manual work.

Modern DBAs increasingly automate:

  • database deployment
  • configuration
  • patching
  • monitoring
  • backup validation
  • failover procedures
  • environment creation
  • operational checks

Technologies such as Ansible, Python and Bash allow database teams to make operations more repeatable and reduce human error.

Oracle and PostgreSQL remain important

Enterprise environments rarely contain only one database technology.

A senior DBA may work with:

Oracle Database

PostgreSQL

Microsoft SQL Server

MySQL

and increasingly cloud database platforms.

The ability to understand the common principles behind these platforms is therefore becoming more important than knowing only one product.

The future of database administration

The role of the DBA is changing.

It is moving from:

„Keep the database running.“

toward:

„Build a reliable database platform that the business can depend on.“

That means combining database expertise with:

  • automation
  • observability
  • cloud
  • security
  • performance engineering
  • high availability
  • disaster recovery
  • collaboration with application teams

The best database administrators are no longer simply operators.

They are database reliability engineers.

PostgreSQL Performance Tuning: Proč je potřeba nejdříve měřit a teprve potom měnit konfiguraci

Ladění výkonu PostgreSQL se často redukuje na změnu několika parametrů v postgresql.conf.

Takový přístup ale může být nebezpečný.

Produkční databáze se nestane rychlejší jen proto, že změníme shared_buffers, work_mem nebo effective_cache_size. Výkon PostgreSQL je výsledkem celého pracovního zatížení – SQL dotazů, execution plans, indexů, statistik, paměti, I/O, WAL, autovacuum, počtu připojení i samotné infrastruktury.

Správný postup je jednoduchý:

Measure → Identify → Change → Validate

tedy:

Měřit → Identifikovat → Změnit → Ověřit

Dokumentace PostgreSQL doporučuje používat EXPLAIN a EXPLAIN ANALYZE k pochopení způsobu, jakým jsou dotazy vykonávány, a k posouzení vlivu statistik na rozhodování optimalizátoru.

Začněte pracovním zatížením

Než začnete měnit konfiguraci, je potřeba zjistit, co se v databázi skutečně děje.

DBA by měl sledovat například:

  • latenci dotazů,
  • počet transakcí,
  • využití CPU,
  • I/O,
  • počet aktivních připojení,
  • locky,
  • používání dočasných souborů,
  • generování WAL,
  • checkpointy,
  • aktivitu autovacuum.

Tím vznikne výkonnostní baseline, vůči které lze následně porovnávat každou změnu.

Stejný princip platí i u Oracle. Ladění výkonu by mělo začínat identifikací skutečného bottlenecku a porovnáním systému s výkonnostní baseline.

Najděte náročné SQL

Jedním z prvních míst, kde hledat problém, je samotná SQL workload.

pg_stat_statements pomáhá identifikovat dotazy, které spotřebovávají nejvíce času a systémových prostředků.

Potom je možné konkrétní dotaz analyzovat například pomocí:

EXPLAIN (ANALYZE, BUFFERS)
SELECT ...
FROM orders
WHERE customer_id = 12345;

Důležitá otázka není pouze:

„Je tento dotaz pomalý?“

Správná otázka zní:

„Proč PostgreSQL tráví jeho vykonáváním tolik času?“

Execution plan může odhalit například:

  • sekvenční skeny,
  • neefektivní JOINy,
  • špatné odhady počtu řádků,
  • zbytečné řazení,
  • práci s dočasným I/O,
  • nevhodné použití indexů.

Nevytvářejte indexy naslepo

Index může dramaticky zrychlit čtení dat.

Každý index ale zároveň něco stojí.

Více indexů znamená:

  • větší spotřebu diskového prostoru,
  • vyšší režii při zápisu,
  • více WAL,
  • další maintenance,
  • větší nároky na VACUUM.

Dobrý DBA se proto neptá:

„Můžeme přidat další index?“

Ale:

„Vyřeší tento konkrétní index skutečný problém?“

Cílem není mít co nejvíce indexů.

Cílem je mít správné access paths pro konkrétní workload.

Autovacuum je součástí performance engineeringu

Autovacuum bývá někdy vnímán pouze jako automatická údržba databáze.

V produkčním PostgreSQL je to chyba.

Špatně nastavený nebo nedostatečně fungující autovacuum může vést k:

  • bloatu tabulek,
  • neefektivním scanům,
  • vyšší spotřebě storage,
  • problémům s transaction ID,
  • vyššímu I/O,
  • degradaci výkonu SQL dotazů.

Výkon PostgreSQL proto nelze oddělit od údržby databáze a transaction behavior.

Konfigurace přichází až potom

Teprve když víme, kde problém skutečně je, má smysl zabývat se parametry jako:

  • shared_buffers,
  • work_mem,
  • effective_cache_size,
  • maintenance_work_mem,
  • max_wal_size,
  • nastavení checkpointů,
  • parametry autovacuum,
  • limity připojení.

Neexistují univerzálně správné hodnoty těchto parametrů.

Správná konfigurace závisí na:

hardware + workload + concurrency

Proto není dobré slepě aplikovat nějaký „optimal PostgreSQL configuration“ z internetu.

PostgreSQL 18 přináší další možnosti

PostgreSQL 18 přinesl několik změn zaměřených také na výkon, například skip-scan optimalizaci pro některé multicolumn indexy, rozšíření informací v EXPLAIN a další změny optimalizátoru.

Pro DBA z toho plyne důležitý závěr:

Performance tuning není jednorázová změna konfigurace.

Je to průběžný proces.

Výkonnostní cyklus DBA

Zralý produkční proces může vypadat takto:

1. Měřit

Vytvořit baseline latence, throughputu a využití zdrojů.

2. Diagnostikovat

Najít skutečný bottleneck pomocí statistik SQL, execution plans, waitů a infrastrukturních metrik.

3. Změnit

Provést co nejmenší změnu, která řeší identifikovaný problém.

4. Ověřit

Znovu změřit stejný workload a ověřit výsledek.

5. Dokumentovat

Zaznamenat změnu, důvod, dopad a případný rollback.

6. Monitorovat

Ověřit, že řešení funguje i v době, kdy se mění data a workload.

Performance tuning není „ladění parametrů“

Tohle je zásadní rozdíl mezi configuration tweaking a skutečným database performance engineeringem.

Configuration tweaking znamená:

„Změňme work_mem a uvidíme.“

Performance engineering znamená:

„Změřme problém, najděme jeho příčinu, proveďme cílenou změnu a následně prokazatelně změřme výsledek.“

A právě tento přístup je základem stabilního a předvídatelného produkčního databázového prostředí.

Measure. Understand. Optimize. Repeat.

Skutečný výkon začíná skutečnými daty.



Komentáře