Single database

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 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 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 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.

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.