Creating More than one Database into Azure Sql Database

Question

Creating More than one Database into Azure Sql Database

pdsqsql 436

Hello,

We have earlier created Azure Sql Server Database and we are trying to add one more database which is ok to have it?

EX.

Server: sqldb-mfr-test.database.windows.net

Database: sqldb-mfr-test

Now we wanted to add another database like "sqldb-mfr-qa" into same Subscription, Same Resource Group under same server "sqldb-mfr-test.database.windows.net"

Should be fine, right?

Any other suggestion please?

0 comments

2 answers

Your answer

Answer 1

Erland Sommarskog 138.3K MVP Volunteer Moderator

You can have as many databases as you want on Azure SQL Server. Well, there probably is a limit, but it is a lot more than two. The one to keep in mind that the "Server" in this context is purely logical. The databases on the server are likely to be running on completely physical servers.

pdsqsql 436 Reputation points

2026-10-20T21:22:57.6066667+00:00

Erland,

Thanks for the resposne.

I was in impression that AZURE Sql DB can have only Single DB (May be using Elastic Pool might can multiple DB?) vs Azure Managed Sql Instance can have multiple databases.
Erland Sommarskog 138.3K Reputation points MVP Volunteer Moderator

2026-10-20T21:26:57.3566667+00:00

A database is one database. But just like on-prem you first create a server, and then a database with that server. But that server is very different. It is a logical concept, and the databases you have on that server are isolated from each other. But authentication can be to the server - but in many cases, it is better to authenticate to the database directly.

Answer 2

Yes, create sqldb-mfr-qa as a second Azure SQL Database under the existing logical server sqldb-mfr-test.database.windows.net.

Create the database

In the Azure portal, open SQL databases.
Select Create.
Choose the existing:
- Subscription
- Resource group
- Server: sqldb-mfr-test
Enter Database name: sqldb-mfr-qa.
Select the required compute and storage configuration, or choose an existing elastic pool.
Select Review + create, then Create.

An Azure SQL logical server is specifically designed as the parent and administrative container for multiple databases. It supplies their common connection endpoint and server-level management settings.^1^

Applications connect to the same server endpoint but specify different database names:

Server=tcp:sqldb-mfr-test.database.windows.net,1433;
Initial Catalog=sqldb-mfr-qa;
Authentication=Active Directory Default;
Encrypt=True;

Important design considerations

Capacity: A logical server supports up to 5,000 databases, subject to subscription and regional compute quotas. Two databases are well within that limit.^2^
Compute and cost: If both are single databases, each has its own service tier, compute allocation, storage configuration, and associated cost.^3^
Elastic pool option: If test and QA have intermittent or unpredictable usage, consider placing them in an elastic pool. Databases in a pool share an allocated set of compute resources, which can reduce costs compared with independently provisioned databases.^4^
Server-scoped configuration: Firewall rules, auditing, threat-detection policies, logins, and some other management policies are scoped to the logical server. Review whether test and QA should share those settings.^1^
Permissions: Users do not automatically receive equivalent database-level permissions in the new database. Create or map the required contained users and grant appropriate roles in sqldb-mfr-qa.
Lifecycle isolation: Deleting the logical server deletes all databases and elastic pools beneath it. Add an Azure resource delete lock to the server or resource group if accidental deletion is a concern.^5^

Using the same logical server is appropriate when test and QA can share the same region, network boundary, server administration, and server-scoped policies. Use separate logical servers when the environments require independent firewall rules, administrators, regional placement, auditing policies, quotas, or lifecycle boundaries.

References