Merge pull request #3917 from MicrosoftDocs/main

learn-build-service-prod[bot] · web-flow · commit 78327efccbcf · 2025-12-15T12:04:51.000Z
Auto Publish – main to live - 2025-12-15 12:00 UTC
diff --git a/articles/cosmos-db/concepts-limits.md b/articles/cosmos-db/concepts-limits.md
@@ -117,15 +117,15 @@ Each resource scales synchronously and immediately between the minimum RU/s and
 
 ### Serverless
 
-[Serverless](serverless.md) lets you use your Azure Cosmos DB resources in a consumption-based fashion. The following table lists the limits for storage and throughput burstability per container/database. These limits can't be increased. Allocate extra serverless accounts for more storage needs.
+[Serverless](serverless.md) lets you use your Azure Cosmos DB resources in a consumption-based fashion.
 
 | Resource | Limit |
 | --- | --- |
-| Maximum RU/s per container | 20,000* |
-| Maximum storage across all items per (logical) partition | 20 GB |
-| Maximum storage per container | 1 TB  |
+| Maximum storage across all items per (logical) partition | 20 GB ¹|
+| Maximum number of distinct (logical) partition keys | Unlimited |
+| Maximum storage per container | Unlimited |
 
-*Maximum RU/sec availability is dependent on data stored in the container. See, [Serverless Performance](serverless-performance.md)
+¹ If your workload reaches the logical partition limit of 20 GB in production, rearchitecting your application with a different partition key is recommended as a long-term solution. To give you time to rearchitect your application, request a temporary increase in the logical partition key limit for your existing application. [File an Azure support ticket](create-support-request-quota-increase.md) and select quota type **Temporary increase in container's logical partition key size**. Requesting a temporary increase is intended as a temporary mitigation and not recommended as a long-term solution. To remove the configuration, file a support ticket and select quota type **Restore container’s logical partition key size to default (20 GB)**. You can file this support ticket after deleting data to fit the 20-GB logical partition limit or rearchitecting your application with a different partition key.
 
 ## Control plane
 
diff --git a/articles/cosmos-db/serverless.md b/articles/cosmos-db/serverless.md
@@ -38,11 +38,36 @@ The Azure Cosmos DB serverless option best fits scenarios in which you expect *i
 
 For more information, see [How to choose between provisioned throughput and serverless](throughput-serverless.md).
 
+### Best practices for multi-tenant applications
+
+When designing multi-tenant applications on Azure Cosmos DB, two isolation models are recommended:
+
+#### Partition key per tenant
+In this model, each tenant is represented as a logical partition key within a container. This approach:
+- Scales efficiently as the number of tenants increases
+- Reduces per-tenant cost by sharing throughput and storage
+- Works well for business-to-consumer (B2C) applications with many smaller tenants
+
+For more information, see the [partition-key-per-tenant](https://aka.ms/CosmosMultitenancy#partition-key-per-tenant-model) model.
+
+#### Database account per tenant
+In this model, each tenant has a dedicated Azure Cosmos DB account. This approach:
+- Provides strong isolation boundaries
+- Allows per-tenant settings such as regional configuration, customer-managed keys, and point-in-time restore
+- Works well for business-to-business (B2B) applications that require differentiated configurations
+
+For more information, see the [database-account-per-tenant](https://aka.ms/CosmosMultitenancy#database-account-per-tenant-model) model.
+
+> [!Note]
+Avoid designing multi-tenant applications with a container-per-tenant or database-per-tenant approach. These patterns can introduce [scalability challenges](concepts-limits.md#serverless-1) as your customer base grows. Instead, use one of the recommended models above to ensure predictable performance and cost efficiency.
+
+For a detailed walkthrough, see [Multi tenancy in Azure Cosmos DB](https://aka.ms/CosmosMultitenancy).
+
 ## Use serverless resources
 
 Azure Cosmos DB serverless is a new account type in Azure Cosmos DB. When you create an Azure Cosmos DB account, you choose between *provisioned throughput* and *serverless* options.
 
-To get started with using the serverless model, you must create a new serverless account. Migrating an existing account to or from the serverless model currently isn't supported.
+To get started with using the serverless model, you must create a new serverless account.
 
 Any container that's created in a serverless account is a serverless container. Serverless containers have the same capabilities as containers that are created in a provisioned throughput account type. You read, write, and query your data exactly the same way. But a serverless account and a serverless container also have other specific characteristics:
 
@@ -72,3 +97,4 @@ Azure Cosmos DB serverless extends high availability support with availability z
 - [Azure Cosmos DB serverless account performance](serverless-performance.md)
 - [How to choose between provisioned throughput and serverless](throughput-serverless.md)
 - [Pricing model in Azure Cosmos DB](how-pricing-works.md)
+- [Multi tenancy in Azure Cosmos DB](https://aka.ms/CosmosMultitenancy)
diff --git a/articles/postgresql/flexible-server/concepts-monitoring.md b/articles/postgresql/flexible-server/concepts-monitoring.md
@@ -4,7 +4,7 @@ description: Review the monitoring and metrics features in an Azure Database for
 author: varun-dhawan
 ms.author: varundhawan
 ms.reviewer: maghan
-ms.date: 4/21/2025
+ms.date: 12/11/2025
 ms.service: azure-database-postgresql
 ms.subservice: flexible-server
 ms.topic: concept-article
@@ -242,11 +242,85 @@ There are several options to visualize Azure Monitor metrics.
 |Overview page|Most Azure services have an **Overview** page in the Azure portal that includes a **Monitor** section with charts that show recent critical metrics. This information is intended for owners of individual services to quickly assess the performance of the resource. |This page is based on platform metrics that are collected automatically. No configuration is required.         |
 |[Metrics Explorer](/azure/azure-monitor/essentials/metrics-getting-started)|You can use Metrics Explorer to interactively work with metric data and create metric alerts. You need minimal training to use Metrics Explorer, but you must be familiar with the metrics you want to analyze. |- Once data collection is configured, no other configuration is required.<br>- Platform metrics for Azure resources are automatically available.<br>- Guest metrics for virtual machines are available after an Azure Monitor agent is deployed to the virtual machine.<br>- Application metrics are available after Application Insights is configured.         |
 | [Grafana](https://grafana.com/grafana/dashboards/21177-azure-azure-postgresql-flexible-server-monitoring/) | You can use Grafana for visualizing and alerting on metrics. All versions of Grafana include the [Azure Monitor datasource plug-in](/azure/azure-monitor/visualize/grafana-plugin) to visualize your Azure Monitor metrics and logs.                                                     | To become familiar with Grafana dashboards, some training is required. However, you can simplify the process by downloading a prebuilt [Azure PostgreSQL Monitoring](https://grafana.com/grafana/dashboards/21177-azure-azure-postgresql-flexible-server-monitoring/), which allows for easy monitoring of all Azure Database for PostgreSQL flexible server instances within your organization.                                                                                                                                              |
-
-
-## Logs
-
-In addition to the metrics, you can use Azure Database for PostgreSQL to configure and access Azure Database for PostgreSQL standard logs. For more information, see [Logging concepts](concepts-logging.md).
+## Azure Database for PostgreSQL resource logs
+
+These are logs generated and collected from operations that occur at the data plane level.
+
+They aren't automatically collected by default. Their collection to a supported external location requires configuration and has associated costs of ingestion, retention and subsequent querying.
+
+These logs are organized in categories and those categories are grouped into category groups.
+
+Following are the logs that, using **Diagnostic Settings** can be streamed to an external destination like a Log Analytics workspace, an storage account, an event hub, or a partner solution:
+
+**Description**: PostgreSQL server logs.<br>
+**Running frequency**: 10 seconds.<br>
+**Category name**: PostgreSQLLogs.<br>
+**Display name**: PostgreSQL Server Logs.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLServerLogs.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLLogs.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetPostgresServerLogs.<br>
+**Additional requirements**: None.<br>
+
+**Description**: Snapshot of active PostgreSQL sessions showing details current database connections and their activity, including session metadata, timing, and wait states.<br>
+**Running frequency**: 5 minutes.<br>
+**Category name**: PostgreSQLFlexSessions.<br>
+**Display name**: PostgreSQL Sessions data.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLPgStatActivitySessions.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLFlexSessions.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetPgStatActivitySessions.<br>
+**Additional requirements**: None.<br>
+
+**Description**: Detailed query performance statistics from PostgreSQL query store.<br>
+**Running frequency**: 5 minutes when `pg_qs.interval_length_minutes` is between 1 and 5. Number of minutes specified in `pg_qs.interval_length_minutes`, when `pg_qs.interval_length_minutes` is higher than 5 minutes.<br>
+**Category name**: PostgreSQLFlexQueryStoreRuntime.<br>
+**Display name**: PostgreSQL Query Store Runtime.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLQueryStoreRuntime.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLFlexQueryStoreRuntime.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetQueryStoreRuntime.<br>
+**Additional requirements**: `pg_qs.query_capture_mode` must be set to either `top` or `all`.<br>
+
+**Description**: What queries were waiting on what wait events and for how long.<br>
+**Running frequency**: 5 minutes when `pg_qs.interval_length_minutes` is between 1 and 5. Number of minutes specified in `pg_qs.interval_length_minutes`, when `pg_qs.interval_length_minutes` is higher than 5 minutes.<br>
+**Category name**: PostgreSQLFlexQueryStoreWaitStats.<br>
+**Display name**: PostgreSQL Query Store Wait Statistics.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLQueryStoreWaits.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLFlexQueryStoreWaitStats.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetQueryStoreWaits.<br>
+**Additional requirements**: `pg_qs.query_capture_mode` must be set to either `top` or `all`, and `pgms_wait_sampling.query_capture_mode` must be set to `on`.<br>
+
+**Description**: Schema-level aggregated statistics about all tables in the database, summarizing table activity and maintenance metrics.<br>
+**Running frequency**: 30 minutes.<br>
+**Category name**: PostgreSQLFlexTableStats.<br>
+**Display name**: PostgreSQL Autovacuum and schema statistics.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLAutovacuumStats.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLFlexTableStats.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetAutovacuumStats.<br>
+**Additional requirements**: None.<br>
+
+**Description**: Database-level view of transaction ID (XID) and multixact ID age and wraparound risk, along with thresholds for autovacuum and emergency vacuum actions.<br>
+**Running frequency**: 30 minutes.<br>
+**Category name**: PostgreSQLFlexDatabaseXacts.<br>
+**Display name**: PostgreSQL remaining transactions.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLDbTransactionsStats.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLFlexDatabaseXacts.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetDbTransactionsStats.<br>
+**Additional requirements**: None.<br>
+
+**Description**: Built-in PgBouncer logs.<br>
+**Running frequency**: 10 seconds.<br>
+**Category name**: N/A.<br>
+**Display name**: N/A.<br>
+**Included in category group**: audit and allLogs.<br>
+**Resource specific table**: PGSQLPgBouncer.<br>
+**Value of Category column when streamed to AzureDiagnostics**: PostgreSQLFlexPGBouncer.<br>
+**Function to concatenate events from AzureDiagnostics and resource specific table**: _PGSQL_GetPgBouncerLogs.<br>
+**Additional requirements**: Built-in PgBouncer must be enabled on the server via setting `pgbouncer.enabled` to `on`.<br>
 
 ### Logs visualization
 
