Yandex Cloud
Search
Discuss with expertTry it for free
  • Customer Stories
  • Documentation
  • Blog
  • All Services
    • Cloud Interconnect
    • Cloud Backup
    • Cloud Registry
    • Yandex AI Studio
    • Compute Cloud
    • Object Storage
    • Managed Service for Kubernetes®
    • Yandex BareMetal
    • Smart Web Security
    • Security Deck
    • Managed Service for PostgreSQL
    • Managed Service for ClickHouse®
    • Monium
    • Cloud CDN
    • Network Load Balancer
    • Virtual Private Cloud
    • Cloud DNS
    • Application Load Balancer
    • Yandex Cloud Video
    • Stackland
    • Yandex Cloud Router
    • Yandex Managed Service for Trino
    • Managed Service for MySQL®
    • Managed Service for Valkey™
    • Managed Service for Apache Spark™
    • Yandex StoreDoc
    • Managed Service for OpenSearch
    • Managed Service for Apache Kafka®
    • Data Transfer
    • Yandex MPP Analytics Engine for PostgreSQL
    • Yandex Managed Service for Apache Airflow®
    • Data Processing
    • Yandex MetaData Hub
    • Managed Service for YDB
    • Managed Service for Sharded PostgreSQL
    • Managed Service for YTsaurus
    • Yandex WebSQL
    • DataLens
    • Yandex Search API
    • SpeechSense
    • SpeechKit
    • DataSphere
    • Vision OCR
    • Translate
    • Yandex Identity Hub
    • Key Management Service
    • Certificate Manager
    • Yandex Lockbox
    • Audit Trails
    • SmartCaptcha
    • Cloud Desktop
    • SourceCraft Code Assistant
    • Container Registry
    • Managed Service for GitLab
    • Managed Service for Prometheus®
    • Cloud Functions
    • API Gateway
    • Yandex Cloud Postbox
    • Message Queue
    • Serverless Integrations
    • IoT Core
    • Data Streams
    • Serverless Containers
    • Cloud Notification Service
    • Yandex Query
    • Identity and Access Management
    • Yandex Cloud Console
    • Resource Manager
    • Yandex Cloud Billing
    • Yandex Cloud Quota Manager
    • Cloud Apps
  • System Status
  • Marketplace
    • Featured
    • Infrastructure & Network
    • Data Platform
    • AI for business
    • Security
    • DevOps tools
    • Serverless
    • Monitoring & Resources
  • All Solutions
    • By industry
    • By use case
    • Economics and Pricing
    • Security
    • Technical Support
    • Start testing with double trial credits
    • Cloud credits to scale your IT product
    • Gateway to Russia
    • Cloud for Startups
    • Center for Technologies and Society
    • Yandex Cloud Partner program
    • Price calculator
    • Pricing plans
  • Customer Stories
  • Documentation
  • Blog
© 2026 Direct Cursus Technology L.L.C.
Yandex Managed Service for PostgreSQL
  • Getting started
    • Resource relationships
    • Planning a cluster topology
    • High availability clusters
    • Networking in Managed Service for PostgreSQL
    • Quotas and limits
    • Storage in Managed Service for PostgreSQL
    • Backups
    • Assigning roles
    • Managing connections
    • Load balancer for hosts
    • Replication
    • Maintenance
    • Supported clients
    • PostgreSQL settings
    • Indexes
    • SQL command limits
    • Upgrading the PostgreSQL major version
    • PostgreSQL versioning policy
  • Access management
  • Pricing policy
  • Terraform reference
  • Monitoring metrics
  • Audit Trails events
  • Public materials
  • Release notes
  1. Concepts
  2. Load balancer for hosts

Load balancer for hosts

Written by
Yandex Cloud
Updated at July 16, 2026
View in Markdown

Managed Service for PostgreSQL allows you to use an internal network balancer to distribute load between hosts. This load balancer operates at layer 4 of the OSI network model, but uses layer 3 technologies to speed up packet processing.

Note

This feature is at the Preview stage. Contact support for access.

Using a load balancer gives you the following advantages:

  • A single entry point for connecting to the master host.
  • Even distribution of read requests among replicas, taking their load into account
  • Choice of load balancing policy. For example, you can set Least connections to distribute load to replicas with the fewest connections.
  • Minimization of cluster unavailability during master failover or changes in the replica composition.
  • To switch the application to a new cluster when restoring from a backup, you just need to replace a single FQDN.

The load balancer automatically accounts for changes in cluster topology: new replicas are included in load balancing, and removed ones are excluded.

In the cluster architecture, the load balancer is implemented as a separate service that can be enabled when creating or modifying a cluster. The load balancer stops and starts simultaneously with the cluster stop and start. The load balancer is assigned a single FQDN common to all availability zones, which serves as a single entry point for all database requests.Incoming traffic to the load balancer is distributed across all hosts in the cluster, and when hosts are added or removed from the cluster, they are automatically added to or removed from balancing.

The network traffic regulation schema for the cluster using a load balancer is shown below:

Warning

We do not recommend creating a Network Load Balancer (NLB) manually for cluster access. The load balancer that is automatically created during cluster deployment has a critically important proxy configuration. Without this configuration, the NLB will block traffic to the handler ports, resulting in loss of access to the cluster.

When the load balancer is enabled, it remains possible to connect directly to the database via the host FQDN, bypassing the load balancer.

A separate proxy service based on Odyssey is used to analyze the state and load of hosts. The proxy service is deployed on each host the following functions:

  • Monitoring host availability.
  • Checking replica lag.
  • Verifying host role.

The load balancer provides several special ports for target connections:

  • Connection only to the master host: port 6432.

  • Connection to replicas with lag less than a predefined value: port 7432.

    For example, to distribute read requests only among replicas with a lag of no more than 30 seconds:

    • Create a cluster with the load balancer enabled and specify a replica lag value of 30 seconds in the 7432 port settings.
    • Specify the database connection string with the load balancer FQDN and port 7432 in your application settings.
  • Connection to all replicas, regardless of lag: port 7433.

Traffic from each open port of the load balancer is directed to the proxy service and then distributed to target connections depending on the port number.

Note

When using a load balancer, client connections remain under the control of the Odyssey connection manager.

Was the article helpful?

Previous
Managing connections
Next
Replication
© 2026 Direct Cursus Technology L.L.C.