[Feature Request] Availability on Azure Database for PostgreSQL

[gliwka]

Purpose of the feature
I would like to use the DocumentDB PostgreSQL extension on Azure Database for PostgreSQL, but it's not currently available in the available extensions list. Given this is a MS extension, is there any chance it can be offered on the Postgres offering hosted by MS?

Describe the solution you'd like
Being able to enable the DocumentDB PostgreSQL extensions in the allowable extensions list for Azure Database for PostgreSQL Flexible Server.

Describe alternatives you've considered

• Self-hosting PostgreSQL - Loses the benefits of Azure's managed Postgres service
• Using the Azure Cosmos DB for MongoDB (vCore) service on Azure - now I have two services to maintain and no way to combine them server-side (only on the client).

Additional context
This would help my team build applications that need both relational and document database capabilities while staying within Azure's PostgreSQL offering without having to deploy and maintain another service on Azure. Plus: being able to combine both models server-side instead of client-side.

[abinav2307]

@gliwka thanks for your request. We'd love to connect with you to understand your scenarios in more depth. Is Postgres your primary use case with a document database experience being the less important use case or the opposite? Moreover, is the ability to have a NoSQL endpoint coupled with an endpoint to the lower Postgres based engine be the reason you are unable to use the vCore based service in Azure?

[gliwka]

This comes mainly from a migration perspective. We're migrating away from different database experiences (graph, document) and consolidating it all in relational postgres for simplicity.

In my mind, it would allow for easier migration strategies if the document database and our relational shared the same backing engine during the migration period due to the following:

• less operational burden for the team (one less db instance and engine to monitor and maintain)
• allows for different migration strategies if everything is colocated on the same engine (e.g. building relational-style views on top of document experiences, having updateable views with INSTEAD OF triggers that update the document side, triggers on tables that update the documents as well)
• Still allows traditional mongo clients to access the data as expected (through a mongodb endpoint, e.g. FerretDB)