This Blog is about the actual status of the development on Microsoft’s side for the Azure Flexible Server for PostgreSQL.
The Flexible Server is announced “GA Ready” at November 30st, after shiftig the GA Raeady date several times.

But there are still some open requirements which are “Post GA”.

1. AD Integration => Post GA, promissed Q2 2022.
2. Customer managed Keys => Post GA, promissed Q2 2022.

According to the latency of 6 month for GA Ready it is expected that Post GA Features will have more or less the same latency.

On the Windows based Single Server for PostgreSQL offering from Microsoft any development is stopped, only bugs will be fixed.
The latest Major PostgreSQL Release which is available on Single Server is PostgreSQL 11, no PostgreSQL 12, no PostgreSQL 13 and no PostgreSQL 14.

The Single Server has many disadvantages, starting with the default collation US-Western 1252 and not stopping with password encryption md5 only.
On the Single Server we found out that with enabling Azure Services to connect, the pg_hba.conf ends up with about 11000 Entries for approx 2.9 million ip address of the Microsoft Universe.

Reading out pg_hba.conf in sql is blocked on the Flexible Server so there we can’t check this, my expectation will be the same.
Using Flexible Server within a privat VNET is mandatory in my mind, there is no possibility for the Azure Services to connect.

The Single Server offering based on big Windows based hosts with many instancies on, reading out postgressql.con with show all; shows ports within the 20000 region used.
To bring the connectivity down to the PostgreSQL default port 5432 Microsoft placed for each instance one gateway around, and there we observed that now and than the ssl connectivity breaks at these gateways.

Restarting the instance is fixing this issue, but it is not part of the monitoring, so no alarming when it is happening.

The Flexible Server based on Ubuntu 18.04 right now, during the customer preview process Microsoft was using for several times the outdated Ubuntu 16.04, hopefully we will not see this in GA Ready state.

The md5 password encryption can be overruled with scram-sha-256 which comes with PostgreSQL 10 and using community packages it is default since PostgreSQL 13.
Azure Felexibe Server for PostgreSQL scram-sha-256 workaround

Microsoft is offering Compute V4 for the Flexible Server offering based on Intel Cascade Lake Xeon CPUs:
Azure Flexibe Server for PostgreSQL Compute V4

The issue here is that Cascade Lake is official not supported by Ubuntu 18.04:
Ubuntu 18.04 CPU Compatibility

The observation was a performance drop using Compute V4:

V3 without replication:

latency average = 8.343 ms
tps = 479.469320 (including connections establishing)
tps = 479.735705 (excluding connections establishing)

V4 without replication:

latency average = 11.734 ms
tps = 340.893181 (including connections establishing)
tps = 341.094725 (excluding connections establishing)

Compute V5 Ice Lake is supported by Ubuntu 18.04, but till now not offered for the Flexible Server by Microsoft, hopefully it will come.
The main performance issue on the Flexible Server is slow storage, update like “Ultra SSD” promissed for 2022, so development is still ongoing.

Microsoft is using synchronus replication, with all pros and cons of sychronous replication.
Ome of the cons is leaking performance:
V3 without replication:

latency average = 8.343 ms
tps = 479.469320 (including connections establishing)
tps = 479.735705 (excluding connections establishing)

V3 with replication:

latency average = 13.797 ms
tps = 289.910220 (including connections establishing)
tps = 290.048492 (excluding connections establishing)

This performance drop is expected by using synchronous replication.
The other con is that GEO redundant replication is not possible and that the replica can not be used read only.

Microsoft is going to Linux, thats good news, we where able to discuss the issues with the Product Group an they are still working on it.
Sometimes it takes very long to fix issues, may be an issue of big organisations in the background, but there is still progress visible.

For now my prefered solution are own virtual machines, there much more options possible according to compute, storage and used OS.
By using an own Linux image with optimized tuned.conf, using Community Packages an the options Microsoft is offering for virutal machines it is possible to build an environment which is much faster, possible to use own SSL keys and certificates and if needed GEO redundant replication.