Managed database servers for PostgreSQL and MySQL.


Flexible database servers now Generally Available

Flexible database servers are now generally available on MedStack Control. Legacy single database servers will no longer be able to be created.

Database servers are Azure managed resources available to use in your compliant environments. They have been provisioned in similar ways as compute nodes to meet the guarantees outlined in MedStack Control's compliance policies.


StatusThe build status of the server from the cloud provider as Creating, Ready, or Deleting.
LabelThe label of the database server (default is the server name)
DatabaseThe database technology and version.
CategoryThe size classification of database server.
VCPUsThe CPU resource specification of the database server.
MemoryThe memory resource specification of the database server.
RoleThe role of the database as the master.
Allowed IPsThe number of allowed IP address rules enabled for the database server.


Database typeSupported versionsTiersMaximum I/OMaximum ConnectionsExtensions
PostgreSQL12, 13, 14, 15Burstable, General Purpose, Memory OptimizedLinkLinkLink
MySQL8.xBurstable, General Purpose, Memory OptimizedLinkLinkN/A

To enable an extension on a flexible database server, please contact our support team using this form.


Building a production system?

Recommended: General purpose tier database servers target most workloads that require balanced compute and memory with scalable I/O throughput. Examples include servers for hosting web and mobile apps and other enterprise applications.

Burstable tier database servers target workloads that require light compute and I/O performance. Examples include servers used for staging, development, testing or small-scale infrequently used applications.


Intrusion detection system

Advanced Threat Protection for Azure Database for PostgreSQL and MySQL is a service used on each database server. It detects anomalous activities indicating unusual and potentially harmful attempts to access or exploit databases and reports this information to MedStack.

SSL connectivity

Azure Database for MySQL supports connecting your database server to client applications using SSL. Enforcing SSL connections between your database server and your client applications helps protect against "man in the middle" attacks by encrypting the data stream between the server and your application.

In some cases, applications require a local certificate file generated from a trusted Certificate Authority (CA) certificate file to connect securely. The certificate to connect to an:

Backup and restore

Azure managed databases for MySQL and PostgreSQL are backed up daily and capture transaction logs to perform a point-in-time restore within the past 35 days.


Restoration creates a new database server

Please note that by restoring a database server, a new database server with the same CPU and Memory resources, and user credentials as were defined when creating the original database server.

Note, the allowed IP list does not replicate on the new database server.

A backup can be restored by:

  1. Click the "Restore from backup" action on a database server.

  2. Select the point in time (UTC) to create the new database server.

  3. Click "Restore" to provision the new database server.

  4. The new database server will be indicated by its label containing the timestamp of the restore point.


New connection string generated

The new restored database server will also have a new database connection string. Please ensure the list of allowed IPs and connection string in the database client are updated accordingly.



  1. Click the Create flexible database button in the cluster you'd like to create a managed database server.
  2. Select the type of database you'd like to create.
  3. Configure the database version from the list of supported versions.
  4. Select the tier and size of the database server as outlined in the specifications section of this guide.
  5. Configure the initial storage capacity. By default, database server storage capacities will automatically scale upward using Azure's autogrow feature.
  6. Create a set of credentials to use for connecting to the database.


Remember your credentials

MedStack does not store your database credentials. If you lose the password for the credentials, you can reset the password. If you lose the entire set of credentials, you may contact [email protected] for assistance.

Reset password

You may reset the password configured for the database server by selecting Reset Password from the Actions menu on a database server row.

It's important to note that you cannot reset the username through MedStack Control.

Allowed IPs

You may permit IP addresses external of the cluster with connection privileges to databases on the server by selecting Allowed IPs from the actions menu on a database server.

You can manage rules here to permit and rescind connections from IP addresses outside the cluster. This is especially helpful when performing a migration, connecting a database between clusters, and troubleshooting a database using a workbench or similar utility hosted on a known IP address.

Common use cases

It is common for allowed IP rules to be used to:

  • Permit cluster access to database servers provisioned in separate clusters on MedStack Control.
  • Manage database servers with database management tools on a web server or local machine.
  • Facilitate database migration processes from external systems into MedStack Control.


You may permanently delete a database server and its backups by selecting Delete from the actions menu on a database server. Only Owner roles can delete database servers.


Make sure you grab a database dump

MedStack cannot guarantee the availability of a database's backups once a database server has been deleted. Before you delete a database server, we recommend you capture a database dump for PostgreSQL or MySQL.


You can establish a connection to a database server by making a URI request with the credentials established when creating the database server and the connection strings.

For more information on connecting to a database server, see our guide advising how to connect to a database .

Connection strings

The connection strings to a database server can be found by clicking on the database technology and version.

SSL certificates

In some cases, applications require a local certificate file generated from a trusted Certificate Authority (CA) certificate file to connect securely. The certificate can be downloaded at:

MedStack does not recommend pinning certificates for SSL connections to your database servers. If you are still experiencing connection issues to your database servers in Azure, please refer to the official Azure documentation on TLS/SSL connectivity:


In this example, we'll walk through both the MedStack Control actions and the application layer modifications to establish a connection to a database server and create a database on the database server.

See the example to learn how to connect databases to your applicaiton.


The default permissions for database extensions are to disallow the installation of extensions. If you would like to install an extension, you must first submit a request to MedStack Support via the help desk to request for the extension to be allowed for install.

  1. Submit a request using this form in the help desk
  2. Wait for the request to be processed, allowing the installation of the database extension
  3. Install the database extension

When the request is processed, the extension is allowed and loaded, but it is not installed. Extensions must be installed in your database before you can use them. To install a particular extension, you should run the CREATE EXTENSION command. This command loads the packaged objects into your database.


How to see a list of allowed database extensions

To see a list of all database extensions that are allowed for installation, you can run the SHOW azure.extensions command for database servers running in Azure clusters on MedStack Control.


Migrating a database can be done easily using the PostgreSQL or MySQL dump and restore functionality.

You must ensure the data is available to be moved into the database. This can be done by:

  • Uploading the dump to a Docker volume.
  • Baking the dump into a container image.
  • Allowing the IP address of a host machine with the dump.

What's next