Connections and Authentication / Connection Settings

bonjour

• What it does: Controls whether the PostgreSQL server advertises its presence via Bonjour (Zero-configuration networking).
• Why it matters: Bonjour advertising can simplify network discovery in macOS and local network environments, but poses security risks in production environments by making your database server discoverable. This feature is primarily useful for development and testing setups where ease of connection is prioritized over security.
• Ideal value & Best Practice: Default off is strongly recommended for production environments. Enable only in controlled development or testing networks where automatic discovery provides tangible benefits. Always disable in internet-facing or production deployments.

bonjour_name

• What it does: Specifies the service name used when advertising the PostgreSQL server via Bonjour.
• Why it matters: When Bonjour is enabled, this name identifies your database service on the network. A descriptive name helps legitimate clients identify the correct service, while a generic name might cause confusion in environments with multiple database instances.
• Ideal value & Best Practice: Default empty (uses computer name). If used, set a unique, descriptive name that identifies the specific database instance without revealing sensitive information. Example: app-dev-db instead of production-database-with-sensitive-data.

listen_addresses

• What it does: Specifies the network interfaces (hostnames or IP addresses) on which PostgreSQL will accept connections.
• Why it matters: This is a critical security parameter that controls network exposure of your database server. Restricting listen addresses minimizes attack surface and prevents unauthorized network access. Proper configuration ensures your database is only accessible from authorized networks or applications.
• Ideal value & Best Practice: For production servers, set to specific IP addresses rather than wildcards. Use localhost for single-machine setups, specific internal IPs for private networks, or * only in controlled environments with other security measures. Never use * in internet-facing deployments.

max_connections

• What it does: Sets the maximum number of concurrent database connections allowed.
• Why it matters: This parameter balances connection availability with system resource constraints. Too few connections can limit application scalability, while too many can cause memory exhaustion and performance degradation. Each connection consumes approximately 5-10MB of memory, making this a crucial resource management setting.
• Ideal value & Best Practice: Default 100 is often too low for production. Calculate based on (available_ram - shared_buffers - other_overhead) / 10MB. Typically 200-500 for medium systems, but use connection pooling (PgBouncer) for applications requiring thousands of connections.

port

• What it does: Defines the TCP port number on which PostgreSQL listens for connections.
• Why it matters: The port setting affects both connectivity and security. Using the default port simplifies connections but may expose your database to automated attacks. Changing the port adds a minor security through obscurity measure while maintaining functionality.
• Ideal value & Best Practice: Default 5432 is acceptable for most environments. Consider changing to a non-standard port in internet-facing deployments to reduce automated attack surface. Ensure firewall rules and client applications are updated accordingly.

reserved_connections

• What it does: Reserves a number of connection slots for specific roles with the pg_use_reserved_connections privilege.
• Why it matters: Ensures that critical maintenance tasks or administrative functions can always connect even when the database reaches its maximum connection limit. This is essential for emergency troubleshooting and maintenance during connection exhaustion scenarios.
• Ideal value & Best Practice: Set to 2-5 connections depending on your administrative needs. Ensure appropriate roles are granted the pg_use_reserved_connections privilege for emergency access.

superuser_reserved_connections

• What it does: Reserves connection slots exclusively for superuser accounts.
• Why it matters: Guarantees that database administrators can always connect for emergency maintenance, even when all regular connection slots are occupied. This is crucial for resolving connection pool issues or performance problems that might prevent normal access.
• Ideal value & Best Practice: Default 3 is reasonable for most environments. Maintain at least 2-3 reserved connections for superusers to ensure reliable administrative access during emergencies.

unix_socket_directories

• What it does: Specifies the directory where Unix-domain sockets are created for local connections.
• Why it matters: Unix-domain sockets provide faster and more secure local connections compared to TCP/IP. The directory location affects both security (through filesystem permissions) and convenience for local client applications.
• Ideal value & Best Practice: Default /tmp or /var/run/postgresql. Use a dedicated directory with restricted permissions for enhanced security. Ensure the directory exists and has proper ownership by the PostgreSQL user.

unix_socket_group

• What it does: Sets the group ownership of the Unix-domain socket.
• Why it matters: Controls which system groups can access the database through local socket connections. Proper group configuration enables secure multi-user access patterns while maintaining isolation from unauthorized users.
• Ideal value & Best Practice: Typically set to postgres or a dedicated database user group. Create a specific group for database users and assign appropriate membership to control socket access.

unix_socket_permissions

• What it does: Sets the filesystem permissions for the Unix-domain socket.
• Why it matters: Socket permissions control which system users can connect to the database locally. Restrictive permissions enhance security by preventing unauthorized local access, while appropriate settings enable legitimate client applications to connect.
• Ideal value & Best Practice: Default 0777 (read/write/execute for all) is permissive. Set to 0770 (group read/write/execute only) or 0700 (user only) for better security. Use 0770 when multiple users in a specific group need access, and 0700 for single-user setups.

---

Try pghealth Free Today 🚀

Properly configuring connection settings is essential for both database security and performance.

With pghealth, you can:

• Analyze your current connection configuration against security best practices
• Identify potential network exposure risks and connection limit issues
• Get tailored recommendations for your specific deployment environment
• Monitor connection patterns and detect anomalous access attempts

Start optimizing your PostgreSQL connection settings today with our free trial — no installation or commitment required.

👉 Start Free Trial Now