Short version: PostgreSQL 15 works after install, but without basic tuning it often behaves like a polite but slightly sleepy server. If you tune memory, WAL, autovacuum, and connection limits early, the database becomes much more stable under real traffic.
What to check first
After installation, do not just check whether the service started. Check whether it is ready for real work:
- PostgreSQL version;
- where data and WAL live;
- how much RAM and CPU the server has;
- whether the database will live through a connection pool or direct connections;
- what kind of workload you expect.
If this is production, do not leave everything on defaults and hope for the best. Defaults are good for bootstrapping, not for sleeping well at night.
Basic settings to tune
1. shared_buffers
This is PostgreSQL’s main cache. On a small or medium server, start conservatively instead of throwing half the RAM at it.
2. work_mem
Do not set it too high, because it is a limit per operation, not for the whole server. If you overdo it, memory disappears fast.
3. wal_buffers and WAL
If WAL sits on a slow disk, write-heavy workloads will feel sluggish. For active systems, a separate WAL disk often helps a lot.
4. autovacuum
Do not disable it because it is noisy. Autovacuum keeps tables healthy. Without it, the database slowly but surely degrades.
Sample postgresql.conf fragment
shared_buffers = 1GB
work_mem = 16MB
maintenance_work_mem = 256MB
wal_buffers = -1
effective_cache_size = 3GB
checkpoint_completion_target = 0.9
max_connections = 100These are not magic numbers for everyone. They are just a sane starting point that must be adjusted for your RAM and workload.
Why it matters
In practice, post-install problems look very ordinary:
- queries exist, but the response is slow;
- the disk is busy and the reason is not obvious;
- the database keeps too many connections and starts choking;
- autovacuum cannot keep up with the cleanup.
So this is not just “optimization”. It is the difference between a server that lasts the day and a server that starts creaking by evening.
How to do it
1. Pick starting values based on the server
First evaluate RAM, CPU, and disk. Only then touch PostgreSQL memory settings.
2. Check the connection pool
If the app opens hundreds of direct connections, PostgreSQL will burn resources for no good reason. In that case the pool is often more important than tiny tuning tweaks.
3. Turn on basic monitoring
Minimum:
- slow queries;
- disk usage;
- active connection count;
- autovacuum activity.
4. Run a smoke test
After changes, verify:
- the database starts;
- reads and writes work;
- logs are clean;
- the main application can connect normally.
5. Do not tune once and forget forever
After a few days of real load, the numbers almost always need another pass. That is normal.
Common mistakes
- Disable autovacuum. That turns into technical debt with interest.
- Set work_mem too high. One query later and the RAM is gone.
- Ignore the WAL disk. Then you end up asking why writes are slow.
- Keep too many direct connections. PostgreSQL is not bottomless.
Conclusion
After installing PostgreSQL 15, the best move is simple: check resources, set safe starting values, keep autovacuum alive, and run a smoke test immediately. That gives you a much better start than waiting for the database to tell you where it hurts.
Official sources:
- https://www.postgresql.org/docs/15/runtime-config-resource.html
- https://www.postgresql.org/docs/15/runtime-config-wal.html
- https://www.postgresql.org/docs/15/routine-vacuuming.html
- https://www.postgresql.org/docs/15/connection-settings.html
- https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server