How to fix FATAL: the database system is starting up in PostgreSQL

PostgreSQLINTERMEDIATEHIGHUpdated Dec 26, 2025· 233 views

This error occurs when you attempt to connect to PostgreSQL while it is still initializing or recovering from an unexpected shutdown. Typically, waiting for the startup process to complete or restarting the database service resolves the issue.

Quick fix

Fixes FATAL: the database system is starting up

# Check if PostgreSQL service is running
sudo systemctl status postgresql

# Or check if the process is active
ps aux | grep postgres

# Use pg_isready to check connection status
pg_isready -h localhost
  1. Check the current PostgreSQL status
  2. Wait for the startup and recovery process to complete
  3. Check the PostgreSQL data directory for issues
  4. Restart PostgreSQL if recovery appears stuck
postgresql — error
# Check if PostgreSQL service is running
sudo systemctl status postgresql
# Or check if the process is active
ps aux | grep postgres
# Use pg_isready to check connection status
pg_isready -h localhost
FATAL: the database system is starting up

What this error means

The "FATAL: the database system is starting up" error is not actually an error condition in the traditional sense, but rather an informational message indicating that the PostgreSQL server is in its initialization phase. After an unclean shutdown or system restart, PostgreSQL must recover by replaying transaction log (WAL) records from the latest checkpoint. During this recovery process, the server accepts connections but rejects queries with this message. The database is inaccessible for regular operations until the recovery process completes, which can take anywhere from seconds to hours depending on the volume of transactions that need to be replayed.

Typical symptoms

  • psql commands fail with "FATAL: the database system is starting up" message
  • Application connections are rejected immediately
  • Database operations fail despite the server process appearing to be running
  • Error persists for longer than expected startup time
  • pg_isready reports that the server is not accepting connections

Common causes

  1. PostgreSQL just started and is still initializing or recovering from a crash
  2. The server did not shut down cleanly and is replaying WAL records for recovery
  3. On a standby (replica) server, hot_standby mode is not enabled and it's still in recovery
  4. Stale lock files left from a previous unclean shutdown
  5. Insufficient system memory causing slow recovery on a VM
  6. High volume of transactions to replay, especially after a long uptime before crash

How to fix "FATAL: the database system is starting up"

1Check the current PostgreSQL status

First, verify that the PostgreSQL server is actually running and observe the startup progress:

bash
# Check if PostgreSQL service is running
sudo systemctl status postgresql

# Or check if the process is active
ps aux | grep postgres

# Use pg_isready to check connection status
pg_isready -h localhost

If pg_isready shows "accepting connections", the server is ready. If it shows "rejecting connections", the startup is still in progress.

2Wait for the startup and recovery process to complete

In most cases, this error resolves itself. The database needs time to complete crash recovery by replaying transaction logs. Wait at least 2-5 minutes before taking further action:

bash
# Monitor PostgreSQL logs to see recovery progress
tail -f /var/log/postgresql/postgresql-15-main.log
# Look for messages like "redo starts at" and "redo done at"

For larger databases with many transactions, recovery can take much longer. Monitor the logs to confirm progress rather than assuming the database is stuck.

3Check the PostgreSQL data directory for issues

If the server appears to be stuck, check the data directory for stale lock files or recovery indicators:

bash
# Check for postmaster PID file and lock
ls -la /var/lib/postgresql/15/main/postmaster.pid

# Check if recovery process is active
ls -la /var/lib/postgresql/15/main/recovery.conf
ls -la /var/lib/postgresql/15/main/standby.signal

Note: Replace "15" with your actual PostgreSQL version and "/var/lib/postgresql" with your actual data directory location.

4Restart PostgreSQL if recovery appears stuck

If the database has been starting up for an unreasonable amount of time, restart the service:

bash
# Gracefully restart PostgreSQL
sudo systemctl restart postgresql

# Wait and check the status
sleep 10
sudo systemctl status postgresql

# Test the connection
psql -U postgres -d postgres -c "SELECT version();"

If a graceful restart doesn't work, try a more forceful approach:

bash
sudo systemctl stop postgresql
sleep 5
sudo systemctl start postgresql
5Verify hot_standby is enabled on replica servers

If this is a standby (replica) server, ensure hot_standby mode is enabled to allow connections during recovery:

bash
# Check the postgresql.conf file
sudo grep hot_standby /etc/postgresql/15/main/postgresql.conf

# It should show: hot_standby = on

If hot_standby is off, enable it:

bash
# Edit the configuration
sudo nano /etc/postgresql/15/main/postgresql.conf

# Find and uncomment/change to:
hot_standby = on

# Reload configuration (no restart needed)
sudo systemctl reload postgresql
6Check and resolve system resource issues

If the startup process is unusually slow, check for resource constraints:

bash
# Check available memory
free -h

# Check disk space
df -h /var/lib/postgresql

# Check CPU usage and load
top -n 1 | head -15

If memory is severely limited (especially on VMs), you may need to:
- Allocate more memory to the VM
- Reduce other services to free up memory
- Consider recovering from backups on a server with more resources

Ensure there is adequate disk space for the recovery process to complete.

Advanced notes

For production environments, consider implementing monitoring for startup/recovery times using tools like pg_stat_progress_recovery (PostgreSQL 12+). If recovery consistently takes too long, investigate transaction log (WAL) size and checkpoint configuration. In high-traffic systems, increasing the number of WAL files or adjusting checkpoint parameters can reduce recovery time. For Patroni-managed clusters, use "patronictl reinit" to recover a failed instance instead of manual restart. The FATAL message is intentionally logged at FATAL level to ensure it appears regardless of log_min_messages settings, so it is not indicative of actual data corruption unless accompanied by other error messages.

Frequently asked questions

What does "FATAL: the database system is starting up" mean?
The "FATAL: the database system is starting up" error is not actually an error condition in the traditional sense, but rather an informational message indicating that the PostgreSQL server is in its initialization phase. After an unclean shutdown or system restart, PostgreSQL must recover by replaying transaction log (WAL) records from the latest checkpoint. During this recovery process, the server accepts connections but rejects queries with this message.
How do I fix "FATAL: the database system is starting up"?
This error occurs when you attempt to connect to PostgreSQL while it is still initializing or recovering from an unexpected shutdown. Typically, waiting for the startup process to complete or restarting the database service resolves the issue.
What causes "FATAL: the database system is starting up"?
PostgreSQL just started and is still initializing or recovering from a crash The server did not shut down cleanly and is replaying WAL records for recovery On a standby (replica) server, hot_standby mode is not enabled and it's still in recovery
Is the "FATAL: the database system is starting up" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading