Database platform foundation: standards every new database should start with

Without a standard, every database becomes a one-off that is hard to patch, monitor and recover. Agree on this once and apply it to every build.

#1. Service tiers

Every database gets a tier before it is built. The tier drives the design, cost and on-call support.

#2. Supported versions

• A list of approved engine versions, for example the current major and the one before it, all within vendor support.
• A date by which anything older must be upgraded, tracked in the CMDB.

#3. Naming

• Hosts: db-<env>-<app>-<nn> (for example db-prd-erp-01). Instances and listeners use DNS aliases that apps connect to, never host names.
• Databases and schemas named after the application, not the person who requested them.

#4. Storage layout

• Separate volumes for data, logs (transaction log / WAL / redo), tempdb or temp, and backups.
• SQL Server: 64 KB allocation unit size for data and log volumes.
• Linux: XFS, noatime. Filesystems sized with 20–30% headroom, plus alerts.

#5. Configuration baseline

• A scripted baseline per engine (memory caps, parallelism, connection limits, logging). See the standalone posts for each engine.
• Time sync (NTP/chrony), UTC on servers, and the time zone handled in the application.
• Antivirus exclusions for data and log files.

#6. Security baseline

• Covered in detail in the security baseline post: no shared admin accounts, TLS, encryption at rest, least privilege, and auditing.

#7. Operations

• Backups set up and one restore tested before go-live.
• Monitoring and alerts enrolled (see the monitoring foundation post).
• Patch group assigned (see the patching policy post).
• Owner, application contact and support hours recorded in the CMDB.

#8. Hand-over checklist (go-live gate)

Tip

Put the baseline in code: Ansible roles, dbatools scripts or Terraform modules. A standard that only exists in a document drifts within months.