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 Sharded PostgreSQL
  • Getting started
    • Resource relationships
    • Sharding
    • Sharding keys
    • Selecting a sharding strategy
    • Host classes
    • Storage in Sharded PostgreSQL
    • Backups
    • Quotas and limits
    • Sharded PostgreSQL settings
    • Sharded PostgreSQL versioning policy
  • Access management
  • Pricing policy
  • Terraform reference
  • Metrics Monitoring
  • Audit Trails events
  • Public materials
  • Release notes
  1. Concepts
  2. Sharded PostgreSQL settings

Sharded PostgreSQL settings

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

For a Managed Service for Sharded PostgreSQL cluster, you can set Sharded PostgreSQL settings.

Sharded PostgreSQL settings are configured at the Managed Service for Sharded PostgreSQL cluster level. You can specify them when creating or updating a cluster.

Router settings (Router → Config):

  • Show Notice Messages

    It determines whether to include additional information, e.g., the shard name, host address, username, transaction status, etc., in the query response.

    This setting is disabled by default, i.e., the response includes no additional information.

    For more on setting up show_notice_messages, see this Sharded PostgreSQL guide.

  • Time Quantiles

    A list of time quantiles for displaying query execution time statistics. Time quantile values are floating-point numbers. If the list is empty, statistics are not collected.

    The default set is [0.5, 0.75, 0.9, 0.95, 0.99, 0.999, 0.9999].

    For more on setting up time_quantiles, see this Sharded PostgreSQL guide.

  • Default Route Behavior

    It determines whether multishard queries are allowed:

    • block: Rejects multishard queries to safeguard data consistency. This is the default option.
    • allow: Allows multishard queries. This is useful for DDL and administrative queries.

    For more on setting up query_routing.default_route_behaviour, see this Sharded PostgreSQL guide.

  • Prefer Same Availability Zone

    If this setting is enabled, read-only queries will go to replica hosts in the router’s availability zone, whenever possible.

    This setting is enabled by default.

  • Enhanced Multishard Processing

    It determines whether to enable enhanced processing for multishard queries.

    For more on setting up query_routing.enhanced_multishard_processing, see this Sharded PostgreSQL guide.

    This setting is disabled by default, i.e., enhanced processing is not perfromed.

  • Default Target Session Attrs

    It defines the default value for the target_session_attrs PostgreSQL parameter indicating the preferred session state when connecting to the database.

    The possible values are:

    • any: Connect to any available host regardless of its state.
    • prefer standby: Prefer replica hosts for connection. If none of them is available, connect to the master host.
    • read only: Connect only to replica hosts. If none of them is available, the connection fails.
    • read write (default): Connect only to the master host. If it is not available, the connection fails.
    • smart read write: Connect to the master host. If it is not available, the connection fails. If the configuration file specifies true for the query_routing.auto_route_ro_on_standby setting, read-only queries are automatically redirected to replica hosts (with the prefer standby semantics).

    For detailed descriptions of the query_routing.default_target_session_attrs and query_routing.auto_route_ro_on_standby settings, see this Sharded PostgreSQL guide.

  • Default Commit Strategy

    It defines the commit strategy for distributed transactions:

    • best effort: One-stage commit without coordination between shards.
    • one pc (default): Alias for best-effort.
    • two pc: Two-stage commit with guaranteed automicity between shards.

    For more on setting up default_commit_strategy, see this Sharded PostgreSQL guide.

Was the article helpful?

Previous
Quotas and limits
Next
Sharded PostgreSQL versioning policy
© 2026 Direct Cursus Technology L.L.C.