Azure Database for PostgreSQL Flexible Server – Query Store and Database Is Alive telemetry stopped after restart

Hello Microsoft Azure PostgreSQL team,

I am requesting technical assistance with an issue affecting an Azure Database for PostgreSQL Flexible Server instance.

I have an active Azure Developer Support plan and am submitting this question through Microsoft Q&A because the Azure Portal is directing Developer Support requests to Q&A.

The PostgreSQL database itself is healthy and fully operational. Applications continue to connect to the database and execute queries normally. However, after a server restart, the Azure Query Store and database activity telemetry stopped collecting new data.

I would like Microsoft engineering to investigate whether there is an issue with the internal Azure PostgreSQL telemetry/Query Store components.

Environment

• Service: Azure Database for PostgreSQL – Flexible Server
• PostgreSQL version: 16.14
• Region: Brazil South

When the issue started

The issue started immediately after a PostgreSQL server restart performed to apply:

max_parallel_workers_per_gather = 0

I am NOT assuming that this parameter caused the problem. I am providing it because the restart was the event immediately preceding the beginning of the issue.

At the time, the database had relatively low activity, so the problem was not immediately noticed.

Later, I performed a complete Stop/Start operation on the Flexible Server, but the issue persisted.

Current symptoms

The following Azure functionality is affected:

1. Database Is Alive metric remains at 0.
2. Query Performance Insight no longer displays query data.
3. Top Queries / most expensive queries are no longer available in the Azure Portal.
4. Query Store stopped recording new query statistics.
5. Query plans are no longer being generated/stored.

However, the following metrics continue to work normally:

• CPU
• Memory
• Connections
• Storage
• Throughput

The application and PostgreSQL engine are also working normally.

Query Store configuration

I verified the following parameters:

pg_qs.query_capture_mode = TOP

pgms_wait_sampling.query_capture_mode = ALL

metrics.collector_database_activity = ON

I also verified that all relevant libraries are loaded in shared_preload_libraries:

pg_cron,

pg_stat_statements,

azure,

pg_qs,

pgaadauth,

pgms_stats,

pgms_wait_sampling,

pg_availability

Therefore, pg_qs, pgms_stats, pgms_wait_sampling and pg_stat_statements are loaded at startup.

azure_sys / Query Store investigation

I connected directly to the internal azure_sys database and confirmed that it exists and is accessible.

The following Query Store views are present:

query_store.qs_view

query_store.query_plans_view

query_store.query_texts_view

The Query Store contains historical query texts:

SELECT COUNT(*) FROM query_store.query_texts;

Result:

1685

However, the query plans table contains no records:

SELECT COUNT(*) FROM query_store.query_plans;

Result:

0

This indicates that query texts exist, but query plans are no longer being generated/stored.

Last Query Store collection

I executed:

SELECT MAX(end_time)

FROM query_store.qs_view;

Result:

2026-05-14 17:26:05.000 -0300

I also calculated the time since the last collection. The result showed that the Query Store has been without new statistics for approximately 81 days.

This is particularly significant because the database has continued to receive and execute queries normally during this entire period.

pgms_stats investigation

I also checked the internal statistics table:

query_stats.pgms_stats_query_counts

The table contains historical records with:

start_time

end_time

querycount

The statistics also stopped updating around the same period.

This suggests that the problem is not isolated to a single Query Store table.

Database Is Alive

The Azure Portal metric:

Database Is Alive

has remained at:

0

However, PostgreSQL is healthy and the application continues to establish connections and execute queries normally.

This appears to indicate that the metric is reporting the state of an Azure telemetry/collector component rather than the actual availability of the PostgreSQL engine.

Restart / Stop-Start

I have already performed:

1. A PostgreSQL server restart.
2. A complete Stop/Start of the Flexible Server.

Neither operation restored the Query Store collection or the Database Is Alive metric.

pg_stat_statements test

As a temporary workaround, I enabled pg_stat_statements.

The module was already present in shared_preload_libraries, but initially:

pg_stat_statements.track = none

After changing the parameter to an active collection mode, pg_stat_statements started collecting query statistics normally.

This confirms that the PostgreSQL engine is executing queries normally and is capable of collecting query statistics.

However, pg_stat_statements only provides statistics from the point at which it was enabled and does not restore the missing Azure Query Store history.

Current impact

The production database itself is NOT unavailable.

The impact is the loss of Azure-managed database monitoring and query-performance functionality:

• Database Is Alive reports 0 incorrectly.
• Query Performance Insight is unavailable.
• Top Queries are unavailable.
• Query plans are not being stored.
• Query Store statistics have not been updated since May 14, 2026.
• Database activity telemetry appears to have stopped.

This prevents us from using the native Azure functionality to monitor database activity and investigate historical query performance.

What I need Microsoft to investigate

Could the Azure PostgreSQL engineering team please investigate the backend components responsible for Query Store and database activity telemetry?

Specifically:

1. Why did Query Store stop recording new statistics after the restart on May 14, 2026?
2. Why is query_store.query_plans empty?
3. Why did pgms_stats stop updating?
4. Why does Database Is Alive remain at 0 while the PostgreSQL engine is healthy?
5. Is there an internal failure in the Azure PostgreSQL telemetry/collector components?
6. Is this a known issue affecting Flexible Server?
7. Was there any platform maintenance, failover, backend event, or internal error around May 14, 2026 at approximately 20:26 UTC?
8. Can Microsoft restart or recover the affected telemetry/Query Store components from the backend?
9. Can the Query Store functionality be restored without recreating or migrating the server?
10. Is there any possibility of recovering the Query Store data that should have been collected after May 14, 2026?

Important clarification

I am not requesting assistance with application query optimization or PostgreSQL configuration.

The database engine is healthy, and I have already verified the relevant PostgreSQL/Azure parameters and performed both restart and Stop/Start operations.

The issue appears to be specifically related to Azure-managed Query Store and telemetry components that are outside the customer's administrative control.

I would appreciate assistance from the Azure Database for PostgreSQL engineering team to determine whether this represents an internal platform issue and, if so, to restore the affected functionality.

I can provide additional SQL output, screenshots, timestamps, or other diagnostic information if required.

Thank you.