Single database

Understand the concept

In plain English

Single database means one Azure SQL Database that stands on its own instead of being placed in an elastic pool or a managed instance. You choose its compute model, service tier, storage, backup redundancy, firewall rules, identities, and monitoring for that database. It is still managed by Azure, so patching, infrastructure maintenance, backups, and high availability are handled by the platform. For learners, the key point is scope: most choices apply to this one database, not every database on the server.

Why it matters

Single databases matter when an application needs predictable ownership and sizing without sharing throughput with unrelated databases. They make cost, performance tuning, backup policy, security review, and deployment risk easier to reason about because the operational blast radius is one database. A team can scale the database up, switch between serverless and provisioned compute where supported, configure zone redundancy, add private connectivity, or restore to a point in time without negotiating an elastic pool. The tradeoff is that underused capacity is not shared, so engineers must watch idle compute, storage growth, and backup retention instead of assuming a pool will absorb waste.

Technical context

Technically, a single database sits in the Azure SQL Database PaaS control plane under a logical SQL server. The logical server provides a DNS name, firewall configuration, admin identity, Microsoft Entra integration, and management scope, while the database owns compute, storage, service tier, backup, auditing, Query Store, and performance settings. Applications connect through the database endpoint, but operators manage it through ARM, Azure SQL APIs, Azure CLI, Bicep, Azure Monitor, and database-level security configuration. This keeps operational ownership explicit.

Exam context

What to know

operator-ready Azure glossary term with practical use cases, CLI context, and structured case studies

Compare with

Where it is used

Where you see it

1. The Azure portal SQL database Overview blade shows database name, server, location, status, pricing tier, compute model, storage usage, and connection guidance during operator review.
2. Azure CLI output from az sql db show exposes serviceObjectiveName, sku, status, edition, zoneRedundant, backupStorageRedundancy, collation, maxSizeBytes, and database identifiers for approved database change evidence.
3. Bicep or ARM templates usually declare Microsoft.Sql/servers/databases with sku, location, zone redundancy, maintenance configuration, auditing, diagnostic settings, and optional private endpoint resources.

Common situations

• Run a separately owned application database that needs independent scale, backup, and restore decisions without sharing compute in an elastic pool.
• Migrate one SQL Server database to Azure SQL Database while keeping application scope small and avoiding managed instance complexity.
• Give a tenant, product, or department its own database boundary for access review, cost tracking, auditing, and change control.
• Use point-in-time restore or geo-restore for one database without affecting other databases on the same logical server.
• Size an unpredictable dev, reporting, or seasonal workload with serverless or provisioned compute based on utilization evidence.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Azure CLI

As an Azure engineer, I use Azure CLI for single databases because database changes often need an audit trail and repeatable proof. Portal screens are fine for exploring, but CLI lets me capture the active subscription, server, database SKU, backup redundancy, zone redundancy, audit policy, firewall exposure, and restore settings before a change. It is also faster during incidents: I can compare production and staging, export JSON for review, or script a resize in a maintenance window. The CLI keeps database work tied to pull requests, runbooks, and change records instead of screenshots that nobody can reproduce. That repeatability avoids guessing.

az sql db list --server <sql-server> --resource-group <resource-group> --output table

az sql db show --name <database> --server <sql-server> --resource-group <resource-group> --output json

az sql db create --name <database> --server <sql-server> --resource-group <resource-group> --service-objective S0

az sql db update --name <database> --server <sql-server> --resource-group <resource-group> --backup-storage-redundancy Geo

az sql db audit-policy show --name <database> --server <sql-server> --resource-group <resource-group>

Architecture context

Architecturally, a single database is a clean boundary for one application component, tenant group, or operational domain. I usually choose it when the workload has clear ownership, needs independent scaling, and does not benefit from pooled compute. The logical server becomes the network and identity anchor, while the database becomes the performance, backup, and data-protection unit. Private endpoints, firewall rules, diagnostic settings, auditing, TDE, Microsoft Entra authentication, and Query Store all need to be designed around that boundary. The main architecture risk is assuming the database is isolated while the application still shares secrets, connection pools, release pipelines, or downstream dependencies.

Security

Security starts with the logical server boundary, then continues at the database. Operators should avoid broad firewall rules, require encrypted connections, prefer Microsoft Entra authentication where practical, and limit SQL users to the permissions they need. Private endpoints reduce public exposure, but they also require DNS, subnet, and application routing checks. Auditing, Defender for SQL, vulnerability assessment, and transparent data encryption help produce evidence and detect risky behavior. The database is isolated from other databases at the service level, but shared application identities, reused admin accounts, or copied connection strings can still turn one compromise into a wider data incident.

Cost

Cost impact is direct because the database owns its compute, storage, backup storage, and optional redundancy choices. Provisioned compute can waste money when the workload is idle, while serverless can save money for intermittent use but may introduce auto-pause and warm-up considerations. Storage growth, long-term retention, geo-redundant backup storage, replicas, zone redundancy, and high service tiers can all add material cost. A single database also lacks the shared-capacity benefit of an elastic pool, so many small quiet databases can be expensive. FinOps checks should track utilization, abandoned dev databases, retention settings, and whether pooled or serverless options fit better. Review those choices with owners during each monthly FinOps pass.

Reliability

Reliability for a single database is mostly about recovery objectives, region design, and safe change. Azure handles platform high availability, backups, and maintenance, but the team still chooses service tier, backup storage redundancy, zone redundancy where available, failover group design, and restore testing. A resize, firewall change, key rotation, or schema deployment can still hurt users if it is done blindly. Operators should measure connection errors, DTU or vCore pressure, storage growth, deadlocks, and failover behavior. The smaller blast radius is useful: one database can be restored or tuned without moving every workload on the logical server. Regular restore drills confirm assumptions.

Performance

Performance is directly tied to the chosen service tier, compute size, storage, query design, indexing, and connection behavior. A single database has dedicated capacity for its database engine, so noisy neighbors inside an elastic pool are not the issue, but bad queries, insufficient vCores, high log writes, tempdb pressure, or missing indexes still are. Query Store, automatic tuning, wait statistics, CPU, data IO, log IO, and connection metrics show where pressure appears. Scaling up can help, but it should follow evidence. Application connection pooling, retry policies, and transaction scope often matter as much as the database SKU. Production baselines make decisions safer.

Operations

Operators manage single databases through a mix of SQL tooling and Azure control-plane checks. Routine work includes reviewing Query Store, checking CPU and storage metrics, verifying backup retention, confirming auditing destinations, testing point-in-time restore, and comparing configuration across environments. Change runbooks should capture the server name, database name, service objective, compute model, region, private endpoint state, firewall rules, and diagnostic settings. During incidents, CLI and KQL queries help distinguish an application connection issue from database saturation, blocked queries, an expired secret, a DNS problem, or a failed deployment. Good operations keep database changes small and reversible. Evidence should be saved after changes.

Common mistakes

• Scaling a single database before checking Query Store, wait stats, and application connection behavior.
• Opening a broad SQL firewall rule to fix connectivity instead of validating private DNS, subnet, and client address.
• Assuming the logical server configuration applies safely to every database without reviewing database-specific settings.
• Leaving development single databases on expensive provisioned tiers after a migration test or performance benchmark.
• Changing backup redundancy, failover, or service tier without documenting the recovery and cost impact.