1) Role Summary

The Senior Database Administrator (Senior DBA) is accountable for the reliability, performance, security, and recoverability of enterprise database platforms that support business-critical applications and services. This role designs and operates highly available database environments, leads complex troubleshooting, and establishes standards and automation that reduce risk and improve service levels.

This role exists in software and IT organizations because databases remain a primary system of record and a frequent operational bottleneck: failures, slow queries, poor data integrity, weak backup practices, and insecure configurations directly impact customer experience, revenue, and regulatory exposure. The Senior DBA creates business value by preventing outages, improving transaction and query performance, enabling compliant data handling, and accelerating delivery teams through self-service patterns and repeatable operating procedures.

• Role horizon: Current (modern DBA practices with automation and cloud-managed services are now mainstream expectations).
• Typical interaction surfaces:
• Application Engineering (backend and platform teams)
• SRE / DevOps and Infrastructure Engineering
• Information Security and GRC (governance, risk, compliance)
• Data Engineering / Analytics (as applicable)
• IT Service Management (Incident/Problem/Change)
• Vendors / managed service partners (context-specific)

2) Role Mission

Core mission: Ensure enterprise database services are consistently available, performant, secure, and recoverable—while enabling application teams to ship changes safely through standards, automation, and well-governed self-service.

Strategic importance: Databases are a convergence point for operational risk (availability and performance), security risk (access and sensitive data), and delivery risk (schema changes, migrations, release coordination). The Senior DBA reduces these risks while improving platform throughput and resilience.

Primary business outcomes expected: – Sustained database service availability aligned to agreed SLOs/SLAs. – Predictable and fast recovery (validated backups, tested restore, DR readiness). – Lower incidence of performance incidents and reduced MTTR when incidents occur. – Secure-by-default database configurations with auditable access controls. – Standardized, automated database operations that reduce manual error and accelerate change delivery. – Cost-effective capacity planning and optimized resource consumption (especially in cloud contexts).

3) Core Responsibilities

Strategic responsibilities (platform direction, standards, risk reduction)

1. Define and maintain database platform standards (configuration baselines, naming standards, parameter policies, HA/DR patterns, maintenance windows) across supported engines.
2. Own database reliability strategy including availability architecture, redundancy, RPO/RTO targets, and operational readiness to meet business continuity requirements.
3. Drive database modernization initiatives such as upgrade programs, engine consolidation, migration to managed services, and deprecation of end-of-life versions.
4. Establish automation-first operating model for provisioning, patching, backup validation, and configuration management to reduce manual drift and operational toil.
5. Partner with Security/GRC to implement database security controls (encryption, key management, logging, least privilege) and ensure audit readiness.

Operational responsibilities (run operations, stabilize services)

6. Own production database operations including monitoring, alerting response, incident support, and on-call participation/escalation for database-related issues.
7. Plan and execute routine maintenance (patching, upgrades, statistics maintenance, index maintenance, vacuuming, storage management) with minimal downtime.
8. Manage backup and recovery lifecycle including backup scheduling, retention, restore testing, point-in-time recovery readiness, and periodic DR exercises.
9. Perform capacity planning (CPU, memory, IOPS, storage growth) and provide forecasts and actionable recommendations to avoid performance degradation/outages.
10. Handle database access administration (roles, permissions, authentication integration, secrets handling) following least privilege and separation of duties.

Technical responsibilities (deep DBA engineering)

11. Lead performance engineering: query optimization, indexing strategy, execution plan analysis, lock/blocking contention mitigation, connection pooling guidance, and parameter tuning.
12. Design and implement high availability (HA) and replication patterns (clustering, read replicas, failover, distributed availability groups, etc.) appropriate to engine and workload.
13. Execute complex migrations across versions/engines/environments (on-prem to cloud, self-managed to managed services, major upgrades) with risk-managed cutover plans and rollbacks.
14. Maintain data integrity and consistency: enforce constraints, manage corruption checks, implement preventive measures, and coordinate data repair procedures when required.
15. Develop and maintain DBA automation using scripting and infrastructure-as-code patterns (backup verification, user provisioning workflows, environment provisioning).

Cross-functional / stakeholder responsibilities (enable teams, reduce friction)

16. Advise engineering teams on schema design, transaction patterns, data access strategies, and operational readiness (e.g., migration scripts, backward-compatible changes).
17. Partner with SRE/DevOps to integrate databases into CI/CD workflows (migration automation, pre-deploy checks, canary strategies, safe rollout patterns).
18. Coordinate with Product/Delivery on release timing, maintenance windows, risk assessments, and post-release validations.
19. Provide operational documentation and training to teams (runbooks, on-call playbooks, “how to request access” workflows, performance best practices).

Governance, compliance, and quality responsibilities (controls and auditability)

20. Implement governance controls: change management, privileged access workflows, logging/auditing, data retention alignment, and evidence collection for audits.
21. Maintain asset and configuration records for databases (CMDB alignment where applicable), including ownership, criticality tiering, and lifecycle status.
22. Define and report service health metrics and operational reviews (trend analysis, problem management inputs, recurring incident elimination).

Leadership responsibilities (Senior IC scope; may lead without formal line management)

23. Mentor and guide DBAs and adjacent engineers through reviews, pairing on incidents, and standard-setting; provide escalation support for complex issues.
24. Lead technical execution on cross-team initiatives (upgrades, DR programs, new platform rollouts), coordinating tasks and setting quality bars.
25. Influence operating model improvements by identifying systemic issues, proposing changes, and driving adoption through stakeholders.

4) Day-to-Day Activities

Daily activities

• Review database monitoring dashboards and alerts; triage and respond to performance anomalies, replication lag, storage thresholds, and backup job failures.
• Support engineering teams with:
• Query tuning and plan analysis
• Index suggestions and validation
• Connection pool sizing and transaction scope guidance
• Review of schema migration approach for upcoming releases
• Validate that scheduled jobs (backups, maintenance, ETL/ELT jobs where applicable) completed successfully and that failures are remediated.
• Handle access requests and privilege reviews (often through ticketing workflows); ensure approvals and evidence are captured.
• Participate in incident response as a database subject matter expert (SME), including rapid containment actions and restoration guidance.

Weekly activities

• Conduct performance and reliability hygiene:
• Identify top expensive queries and regressions
• Review slow query logs / wait events / locking metrics
• Validate replication health, failover readiness signals, and HA status
• Execute planned changes (patching, minor upgrades, configuration adjustments) via change management.
• Review backup and restore evidence (automated verification reports; spot-check restores).
• Participate in engineering rituals:
• Release readiness reviews for database-impacting changes
• Architecture/design reviews for new services or major features
• Meet with Security/GRC on open findings, upcoming audits, and control enforcement status.

Monthly or quarterly activities

• Run DR preparedness activities:
• Tabletop exercises (monthly/quarterly depending on criticality)
• Partial or full restore tests, point-in-time recovery drills
• Replication/failover testing in non-production or controlled windows
• Execute major upgrade planning:
• Version roadmaps, compatibility testing, driver updates coordination
• Deprecation of legacy features and end-of-life technology remediation
• Capacity and cost reviews:
• Growth forecasting, reserved capacity planning (cloud), storage tiering decisions
• Identification of overprovisioned instances and optimization opportunities
• Operational reviews:
• Problem management trends, top incident root causes, recurring alert analysis
• Update runbooks and improve automation coverage

Recurring meetings or rituals

• Daily/weekly operations stand-up (DBA/Platform Ops)
• Incident review / post-incident review (as needed)
• Change advisory board (CAB) / change review (weekly; enterprise-context)
• Release readiness meeting with engineering and SRE/DevOps (weekly/biweekly)
• Monthly service review with stakeholders (availability, performance, risk posture)
• Quarterly risk and compliance review (audit prep, policy alignment)

Incident, escalation, or emergency work

• On-call rotation (primary/secondary) for P1/P2 incidents involving:
• Database unavailability, failovers, corruption signals
• Severe performance degradation (lock storms, I/O saturation, runaway queries)
• Replication breakage, backup failures, storage exhaustion
• Emergency mitigation actions may include:
• Killing runaway sessions, throttling workloads, applying hot indexes (where safe)
• Failing over to a replica, promoting standby, or restoring from backup
• Implementing temporary guardrails (timeouts, connection caps)
• Post-incident responsibilities:
• Provide incident timeline inputs, technical root cause analysis (RCA)
• Implement preventive actions (alerts, config changes, coding guidelines, runbooks)

5) Key Deliverables

Concrete deliverables expected from a Senior Database Administrator typically include:

• Database platform standards and baselines
• Engine-specific configuration baselines
• Hardening checklists and compliance mappings
• Standard operating procedures for provisioning and changes
• Runbooks and operational playbooks
• Incident response playbooks (performance, failover, restore)
• Maintenance runbooks (patching, upgrades, index/statistics routines)
• DR runbooks with validated steps and decision trees
• HA/DR architecture and evidence
• HA topology diagrams (per critical system)
• RPO/RTO alignment documentation
• DR test plans and post-test reports with action items
• Backup and recovery artifacts
• Backup policies (retention, encryption, immutability where applicable)
• Restore test evidence and automation reports
• Point-in-time recovery procedures
• Performance engineering outputs
• Performance assessment reports (top queries, top waits, bottlenecks)
• Index strategy proposals and measured outcomes
• Capacity model and growth forecasts
• Automation and tooling
• Scripts/modules for provisioning, compliance checks, backup verification
• Infrastructure-as-code components (context-specific)
• Self-service workflows for access requests and environment creation (where feasible)
• Change management documentation
• Change plans, cutover/rollback plans
• Risk assessments for major upgrades/migrations
• Maintenance window communications templates
• Dashboards and reporting
• Availability/SLO dashboards for database services
• Backup success/restore readiness dashboards
• Performance and capacity dashboards
• Training and enablement
• Engineering best practices guides (migrations, query patterns, schema design)
• Brown-bag sessions or onboarding materials for developers and junior DBAs

6) Goals, Objectives, and Milestones

30-day goals (orientation and stabilization)

• Build a complete inventory of production database instances/services, owners, criticality tiers, and dependencies.
• Understand current HA/DR posture, backup policies, maintenance schedules, and incident history.
• Establish access to monitoring, ticketing, and runbooks; validate “break-glass” access procedures.
• Identify top operational risks (e.g., failing backups, storage nearing capacity, unsupported versions).
• Deliver quick wins:
• Fix recurring backup failures
• Improve key alerts (reduce noise; add missing critical signals)
• Address obvious performance regressions (top 1–3 issues)

60-day goals (standardization and measurable improvements)

• Publish or update engine-specific standards (configuration baselines, patch cadence, access patterns).
• Implement or enhance automated backup verification and restore testing for Tier-1 systems.
• Complete at least one performance optimization initiative with measured improvement (latency, CPU, I/O).
• Create a prioritized modernization backlog: upgrades, consolidation, migration, or automation opportunities.
• Improve incident response readiness:
• Ensure on-call playbooks are current
• Run at least one incident simulation / tabletop exercise

90-day goals (platform leadership and scale)

• Deliver a 6–12 month database platform roadmap aligned with SRE/Infrastructure and Security.
• Reduce critical incident recurrence by addressing root causes for top 2–3 problem themes.
• Implement repeatable automation for provisioning and baseline compliance checks.
• Establish a predictable change model:
• Regular maintenance windows
• Pre-change validation steps
• Post-change verification checklists
• Mentor junior DBAs/engineers through at least two structured knowledge-sharing sessions.

6-month milestones (operational excellence)

• Achieve consistent backup/restore readiness for Tier-1 and Tier-2 systems (documented evidence and pass-rate targets).
• Improve reliability metrics (availability and MTTR) through automation and better detection/response.
• Complete at least one major upgrade/migration (e.g., legacy engine version to supported version) with controlled downtime and verified rollback plan.
• Implement standardized access governance (role templates, periodic access reviews, privileged session logging where applicable).
• Establish capacity forecasting cadence and cost optimization proposals (especially in cloud).

12-month objectives (enterprise-grade maturity)

• Measurable reduction in high-severity database incidents (year-over-year).
• All production databases aligned to supported versions and patch compliance targets (or documented risk acceptance).
• DR program maturity:
• Regular DR tests executed
• Findings tracked to closure
• RPO/RTO consistently met for Tier-1 services
• Mature self-service enablement:
• Standard database provisioning templates
• Automated policy enforcement
• Developer guidance embedded in delivery workflows
• Demonstrated cost and performance efficiencies (rightsizing, storage optimization, query efficiency improvements).

Long-term impact goals (2+ years; within “Current” horizon but strategic)

• Shift DBA operating model from manual operations to product-like platform ownership:
• “Database platform as a service” mindset
• Standard APIs/workflows for provisioning and access
• Institutionalize proactive reliability engineering (predictive capacity, pre-release performance testing, continuous tuning).
• Strengthen security posture with “secure by default” patterns and continuous compliance checks.

Role success definition

The role is successful when database services are boring—in a good way: stable availability, predictable performance, fast recovery, audit-ready controls, and minimal heroics required during releases.

What high performance looks like

• Anticipates failures (capacity, storage, replication, certificate expiry) and prevents incidents.
• Resolves complex issues quickly with disciplined diagnostics and clear communication.
• Builds scalable mechanisms: automation, standards, and training that reduce reliance on individual expertise.
• Trusted advisor to engineering leadership on data persistence patterns and risk tradeoffs.
• Maintains high operational rigor without becoming a bottleneck to delivery.

7) KPIs and Productivity Metrics

The metrics below are designed to be measurable in real operating environments. Targets vary by tier (Tier-1 vs Tier-3), regulatory demands, and architecture (managed vs self-managed).

Metric name	What it measures	Why it matters	Example target / benchmark	Frequency
Database service availability (per tier)	Uptime of database services supporting production apps	Directly impacts customer experience and revenue	Tier-1: 99.9–99.99%; Tier-2: 99.5–99.9%	Monthly
Error budget burn (DB-related)	Portion of SLO error budget consumed due to DB issues	Helps prioritize reliability work and prevent chronic instability	< 25% burn/month for Tier-1	Weekly/Monthly
P1/P2 incident count (DB-caused)	Number of high-severity incidents attributable to DB platform/config/ops	Indicates reliability and operational maturity	YoY reduction; target depends on baseline	Monthly/Quarterly
Mean time to detect (MTTD)	Time from issue onset to alert/recognition	Faster detection reduces customer impact	Tier-1: < 5–10 min	Monthly
Mean time to restore (MTTR)	Time to recover service after DB incident	Operational effectiveness	Tier-1: < 60 min (context-dependent)	Monthly
Backup success rate	Percent of scheduled backups completed successfully	Foundational for recovery	≥ 99% success	Daily/Weekly
Restore test pass rate	Percent of restore tests completing successfully with evidence	Ensures backups are usable	Tier-1: 100% monthly/quarterly tests; Tier-2: ≥ 95%	Monthly/Quarterly
Achieved RPO / RTO	Actual recovery point/time achieved in tests and incidents	Measures DR readiness	Meet or exceed committed RPO/RTO	Quarterly
Replication lag (p95/p99)	Delay between primary and replica	Impacts failover safety and read scaling	p95 < X sec/min per workload	Daily/Weekly
Performance SLO (query/txn latency)	End-to-end DB latency for critical transactions	Key to application performance	e.g., p95 < 50–200ms (workload-specific)	Weekly/Monthly
Top query regression rate	Frequency of query performance regressions after releases	Indicates release discipline and tuning effectiveness	Trending downward; target < 1 major regression/month	Monthly
Capacity forecast accuracy	Accuracy of growth predictions vs actual	Avoids emergencies and overprovisioning	±10–20% over 3–6 months	Quarterly
Cost efficiency (cloud)	Spend vs baseline; cost per workload	Controls OPEX and encourages rightsizing	X% savings or avoid X% growth	Monthly/Quarterly
Change success rate (DB changes)	Percent of DB-related changes implemented without incident/rollback	Measures change reliability	≥ 95–98% success	Monthly
Patch/upgrade compliance	Percent of instances on approved versions/patch levels	Reduces security and stability risk	≥ 95% within SLA windows	Monthly
Security findings closure time	Time to remediate DB-related security issues	Limits exposure window	e.g., Critical < 7 days; High < 30 days	Weekly/Monthly
Privileged access review completion	Completion of periodic access certifications	Audit and least privilege	100% on schedule	Quarterly/Semiannual
Automation coverage	Percent of key ops tasks automated (provisioning, checks, backups validation)	Reduces toil and human error	Increasing trend; e.g., 60–80% coverage	Quarterly
Stakeholder satisfaction (engineering)	Satisfaction with DBA responsiveness and enablement	Indicates platform usability and partnership	≥ 4.2/5 (internal survey)	Quarterly
Knowledge base/runbook freshness	Percent of runbooks updated within last X months	Maintains readiness	≥ 90% updated within 6–12 months	Quarterly
Mentorship impact (if applicable)	Contributions to team capability (training, reviews)	Scales expertise	1–2 sessions/month; positive feedback	Quarterly

8) Technical Skills Required

Skill expectations vary by engine mix. A Senior DBA is expected to be fluent in at least one major RDBMS and competent across others in the environment, with strong principles transferable across engines.

Must-have technical skills

• Relational database administration (RDBMS)
• Description: Core administration of enterprise relational databases (installation/configuration, maintenance, upgrades, operational troubleshooting).
• Typical use: Daily operations, incident response, ensuring stable service.
• Importance: Critical
• Backup, recovery, and disaster recovery (DR)
• Description: Designing and validating backup strategies; performing restores; meeting RPO/RTO; DR testing.
• Typical use: Regular restore tests, incident recovery, DR exercises.
• Importance: Critical
• Performance tuning and troubleshooting
• Description: Indexing, statistics, execution plan analysis, wait event analysis, locking/deadlock troubleshooting.
• Typical use: P1/P2 performance incidents, proactive optimization, release readiness.
• Importance: Critical
• SQL proficiency
• Description: Ability to read/write SQL to analyze workloads, identify bottlenecks, and validate data.
• Typical use: Diagnostics, reporting on operational metrics, supporting developers.
• Importance: Critical
• High availability and replication concepts
• Description: Clustering, failover, replication, quorum concepts, consistency tradeoffs.
• Typical use: Designing resilient architectures and executing failovers.
• Importance: Critical
• Security fundamentals for databases
• Description: Least privilege, encryption at rest/in transit, audit logging, secrets management integration, hardening.
• Typical use: Access provisioning, compliance, audit support.
• Importance: Critical
• Linux/Windows systems administration basics (DB hosting context)
• Description: OS-level troubleshooting, storage, networking basics, process/resource analysis.
• Typical use: Root-cause analysis of CPU/memory/I/O issues impacting databases.
• Importance: Important
• Monitoring/observability for database systems
• Description: Interpreting metrics/logs/traces; tuning alerts; establishing SLOs.
• Typical use: Detecting issues, reducing noise, preventing outages.
• Importance: Important
• Change management discipline
• Description: Controlled execution of production changes with risk assessment, approvals, and rollbacks.
• Typical use: Patching, upgrades, maintenance windows, migrations.
• Importance: Important

Good-to-have technical skills

• Cloud database services (managed DB)
• Description: Operation of cloud-native DB services (e.g., AWS RDS/Aurora, Azure SQL, Cloud SQL) including backup, scaling, parameter groups, HA options.
• Typical use: Modernization programs and day-to-day ops in cloud.
• Importance: Important (Critical in cloud-first orgs)
• Automation and scripting
• Description: Scripting in Python/PowerShell/Bash; API-driven operations; repeatable automation.
• Typical use: Provisioning, compliance checks, backup validation, user management workflows.
• Importance: Important
• Infrastructure as Code (IaC) basics
• Description: Using Terraform/CloudFormation/ARM/Bicep or similar to provision DB infrastructure and supporting components.
• Typical use: Standardizing environments and reducing drift.
• Importance: Optional (becomes Important in DevOps-oriented orgs)
• Database migration tooling and approaches
• Description: Logical/physical migration methods; replication-based cutovers; data validation; rollback planning.
• Typical use: Upgrade and migration initiatives.
• Importance: Important
• Data modeling fundamentals
• Description: Normalization, constraints, indexing implications, transactional consistency.
• Typical use: Advising application teams and reviewing schema changes.
• Importance: Optional (Important where DBAs do more schema governance)

Advanced or expert-level technical skills

• Engine internals and deep diagnostics
• Description: Advanced understanding of storage engines, concurrency control, WAL/redo logs, cache behavior, and internal instrumentation.
• Typical use: Complex performance/consistency issues, corruption investigations.
• Importance: Important (Critical for Tier-1 environments)
• Advanced HA/DR engineering
• Description: Multi-region designs, automated failover orchestration, cross-engine replication patterns, DR in hybrid environments.
• Typical use: Business continuity for mission-critical systems.
• Importance: Important
• Security engineering depth
• Description: Encryption key lifecycle (KMS/HSM), advanced auditing, privileged access management, token-based auth integration, data masking strategies.
• Typical use: Regulated environments, audit-heavy orgs.
• Importance: Important
• Capacity engineering and workload management
• Description: Modeling IOPS/throughput, partitioning strategies, workload isolation, resource governance.
• Typical use: Preventing saturation and noisy-neighbor issues.
• Importance: Important
• Release engineering integration
• Description: Safe migration patterns (expand/contract), backward-compatible schema evolution, online schema changes, blue/green for DB when feasible.
• Typical use: Supporting frequent releases without downtime.
• Importance: Important

Emerging future skills for this role (next 2–5 years, still “Current” trajectory)

• Policy-as-code and continuous compliance for DB
• Description: Automated detection and enforcement of configuration baselines and access rules.
• Typical use: Reducing audit burden and preventing drift.
• Importance: Optional (increasingly Important)
• Database reliability engineering (DBRE) practices
• Description: Formal SLOs/error budgets, toil management, blameless postmortems, proactive reliability work.
• Typical use: Operational maturity programs.
• Importance: Important
• FinOps for database platforms
• Description: Cost governance, rightsizing automation, storage lifecycle policies, spend attribution.
• Typical use: Cloud database optimization.
• Importance: Optional (increasingly Important in cloud-heavy orgs)
• AI-assisted diagnostics and tuning
• Description: Using AI features in observability tools and DB platforms for anomaly detection and optimization suggestions, with human validation.
• Typical use: Faster triage and proactive optimization.
• Importance: Optional

9) Soft Skills and Behavioral Capabilities

1) Incident leadership and calm execution

• Why it matters: Database incidents are high-stakes and time-sensitive; panic increases error risk.
• How it shows up: Structured triage, clear action plan, controlled changes, decisive escalation.
• Strong performance looks like: Restores service quickly, communicates clearly, and leaves the system safer than before.

2) Analytical problem solving (root cause mindset)

• Why it matters: Many DB issues are multi-layered (application, network, storage, query patterns).
• How it shows up: Hypothesis-driven debugging; uses evidence (metrics, logs, query plans) rather than guesswork.
• Strong performance looks like: Accurate root cause, not just symptom relief; durable corrective actions.

3) Risk judgment and change discipline

• Why it matters: Database changes can be irreversible or cause systemic outages.
• How it shows up: Uses checklists, pre-change validation, rollback planning, change windows aligned to business risk.
• Strong performance looks like: High change success rate; minimal emergency change frequency.

4) Stakeholder communication (technical-to-nontechnical translation)

• Why it matters: Business owners need clarity on impact, ETA, and tradeoffs; engineers need actionable guidance.
• How it shows up: Status updates during incidents; written proposals; clear documentation.
• Strong performance looks like: Stakeholders trust timelines and recommendations; fewer misunderstandings.

5) Ownership and service orientation

• Why it matters: Databases are shared platforms; reliability depends on consistent ownership.
• How it shows up: Proactively tracks issues to closure; follows up on recurring problems; improves runbooks.
• Strong performance looks like: Reduced toil, fewer repeated incidents, improved platform satisfaction.

6) Influence without authority (Senior IC behavior)

• Why it matters: DBAs often must drive standards across multiple engineering teams.
• How it shows up: Persuasive recommendations with data; collaborative design reviews; pragmatic compromises.
• Strong performance looks like: Standards adopted broadly; reduced exceptions; better developer experience.

7) Coaching and mentorship

• Why it matters: Scaling database expertise reduces single points of failure.
• How it shows up: Reviews migration scripts, teaches troubleshooting patterns, pairs on incidents.
• Strong performance looks like: Junior team members become more autonomous; fewer escalations for routine issues.

8) Documentation rigor

• Why it matters: In incidents, documentation becomes the fastest path to safe action.
• How it shows up: Maintains runbooks, diagrams, decision logs, and evidence for audits.
• Strong performance looks like: Anyone on-call can follow playbooks; audit requests are handled efficiently.

10) Tools, Platforms, and Software

Tooling varies by environment; items below reflect realistic enterprise usage and are labeled Common, Optional, or Context-specific.

Category	Tool / platform / software	Primary use	Adoption
Database engines (RDBMS)	PostgreSQL	Core transactional DB engine; HA/replication; performance tuning	Common
Database engines (RDBMS)	Microsoft SQL Server	Enterprise OLTP; HA (Always On); operational tooling	Common
Database engines (RDBMS)	Oracle Database	Enterprise OLTP; advanced features; regulated workloads	Context-specific
Database engines (RDBMS)	MySQL / MariaDB	OLTP and service backends; replication	Common
Cloud platforms	AWS	Hosting databases, networking, IAM integration	Common
Cloud platforms	Microsoft Azure	Hosting databases, identity, governance	Common
Cloud platforms	Google Cloud	Hosting databases and supporting services	Optional
Managed DB services	AWS RDS / Aurora	Managed backups, patching options, replicas, scaling	Common
Managed DB services	Azure SQL / SQL Managed Instance	Managed SQL Server capabilities	Common
Managed DB services	Cloud SQL	Managed Postgres/MySQL	Optional
OS / hosting	Linux	Primary OS for many DB deployments	Common
OS / hosting	Windows Server	Common for SQL Server deployments	Common
Monitoring / observability	Datadog	DB monitoring, dashboards, alerting	Common
Monitoring / observability	Prometheus + Grafana	Metrics collection and visualization	Common
Monitoring / observability	CloudWatch / Azure Monitor	Cloud-native monitoring and logs	Common
Monitoring / observability	New Relic / Dynatrace	APM + infrastructure/DB visibility	Optional
DB performance tools	pg_stat_statements (Postgres)	Query stats for tuning	Common (Postgres shops)
DB performance tools	SQL Server DMVs	Diagnostics and tuning	Common (SQL Server shops)
DB admin clients	SSMS (SQL Server Management Studio)	Admin and troubleshooting	Common
DB admin clients	psql / pgAdmin	Admin, queries, troubleshooting	Common
DB admin clients	Oracle Enterprise Manager	Oracle monitoring/admin	Context-specific
ITSM	ServiceNow	Incident/problem/change, request workflows	Common
Collaboration	Slack / Microsoft Teams	Incident comms, stakeholder updates	Common
Documentation	Confluence / SharePoint	Runbooks, standards, evidence	Common
Source control	GitHub / GitLab / Bitbucket	Versioning scripts, schema migrations, IaC	Common
CI/CD	GitHub Actions / GitLab CI / Azure DevOps	Automate checks, migrations, deployments	Common
Secrets management	HashiCorp Vault	Secrets storage and rotation	Optional
Secrets management	AWS Secrets Manager / Azure Key Vault	Credential storage, rotation integration	Common
Automation / scripting	Python	Automation, tooling, integrations	Common
Automation / scripting	PowerShell	Windows/SQL Server automation	Common
Automation / scripting	Bash	Linux automation	Common
IaC	Terraform	Provision DB infra and policies	Optional (Common in platform teams)
Config management	Ansible	Server config and orchestration	Optional
Container / orchestration	Kubernetes	DB-adjacent tooling; sometimes DB hosting	Context-specific
Security / IAM	Active Directory / Entra ID	Auth integration for SQL Server and enterprise access	Common
Security / audit	SIEM (Splunk, Sentinel, etc.)	Centralized log/audit analysis	Common
Testing / QA	Load testing tools (JMeter, k6)	Validate performance changes	Optional
Migration tooling	Flyway / Liquibase	Schema migration management	Optional (Common in DevOps orgs)
Migration tooling	AWS DMS / Azure DMS	Data migration and replication-based cutovers	Context-specific

11) Typical Tech Stack / Environment

Infrastructure environment

• Hybrid is common in Enterprise IT:
• On-prem virtualization (e.g., VMware) for legacy and certain regulated workloads (context-specific).
• Cloud infrastructure (AWS/Azure commonly) for new services and managed database adoption.
• Storage and network complexity often matters:
• SAN/NAS or cloud block storage performance characteristics.
• Network segmentation and firewalling between app tiers and DB subnets.

Application environment

• Mix of:
• Line-of-business applications (ERP/CRM integrations, internal platforms)
• Customer-facing services (APIs, web apps) owned by product engineering
• DBAs often support multiple application patterns:
• OLTP transactional workloads
• Reporting/operational analytics (sometimes on replicas)
• Batch workloads with heavy write bursts

Data environment

• Predominantly relational operational stores; may integrate with:
• Caching layers (e.g., Redis) that shift traffic patterns
• Data pipeline tools (context-specific)
• Analytics warehouses (context-specific)
• Senior DBA typically focuses on operational databases, not full data engineering ownership—though partnership is frequent.

Security environment

• Strong emphasis on:
• Network segmentation (private subnets, restricted ingress)
• Central IAM integration (AD/Entra, IAM roles)
• Encryption at rest and TLS in transit
• Centralized logging and audit trails into SIEM
• Periodic access reviews and privileged workflows

Delivery model

• Mixed ITIL and DevOps reality:
• Formal change management and CAB for higher-risk changes
• Increasing automation and CI/CD for repeatable changes
• Mature organizations adopt “paved roads”:
• Standard DB templates and golden configurations
• Approved patterns for schema changes and releases

Agile or SDLC context

• DBAs participate in:
• Release planning for schema-impacting features
• Design reviews for data persistence decisions
• Production readiness reviews (SRE-style) for new services

Scale or complexity context

• Typical complexity drivers:
• Large numbers of DB instances across environments
• Multiple engines and versions
• Strict RPO/RTO requirements for Tier-1 systems
• High concurrency workloads and performance sensitivity
• Audit/regulatory requirements (varies by industry)

Team topology

• Common topology in Enterprise IT:
• DBA/Database Services team within Enterprise Platforms or Infrastructure Operations
• Close collaboration with SRE/DevOps, Security, and App Engineering
• Senior DBA often acts as:
• Tier-3 escalation
• Platform steward for standards and reliability programs

12) Stakeholders and Collaboration Map

Internal stakeholders

• Head/Manager of Enterprise Platforms or Infrastructure Operations (Reports To)
• Collaboration: priorities, roadmap, risk acceptance, staffing/on-call.
• SRE / DevOps / Platform Engineering
• Collaboration: monitoring, incident response, CI/CD, IaC, platform patterns, reliability engineering.
• Application Engineering teams
• Collaboration: schema design, query tuning, release coordination, performance troubleshooting, migration readiness.
• Information Security (AppSec/InfraSec)
• Collaboration: controls implementation, vulnerability remediation, encryption, audit logging, secrets handling.
• GRC / Internal Audit
• Collaboration: evidence gathering, access review attestations, policy compliance, audit response.
• IT Service Management (Incident/Problem/Change)
• Collaboration: incident comms, RCA processes, change approvals, change calendars.
• Enterprise Architecture
• Collaboration: standards alignment, modernization decisions, technology lifecycle management.
• Finance / FinOps (cloud-heavy contexts)
• Collaboration: cost optimization, chargeback/showback, reserved capacity strategy.

External stakeholders (as applicable)

• Vendors / cloud providers
• Collaboration: support cases, escalation, RCA, roadmap alignment for managed services.
• Managed service providers
• Collaboration: operational responsibilities split, SLAs, runbook alignment, handoffs.

Peer roles

• Database Administrator (mid-level), Junior DBA
• Systems Administrator / Infrastructure Engineer
• SRE
• Security Engineer / IAM Engineer
• Data Engineer (adjacent)

Upstream dependencies

• Network and firewall provisioning
• Identity/IAM and secrets management tooling
• Storage systems and cloud account governance
• Application release pipelines and migration tooling

Downstream consumers

• Production applications and services
• Reporting tools and operational dashboards
• Internal teams requiring database environments (dev/test)
• Audit/compliance consumers of evidence and logs

Nature of collaboration

• Advisory + enablement: establish patterns and guardrails rather than being the sole executor of every change.
• Operational partnership: shared incident response with SRE/DevOps and application owners.
• Governance partnership: align controls with Security/GRC while maintaining operational practicality.

Typical decision-making authority

• Senior DBA commonly has authority over:
• Operational configuration and maintenance procedures
• Performance tuning and indexing strategies (with change controls)
• Backup/restore approach and tooling selection (within standards)
• Shared authority with:
• Application owners on schema design and release timing
• Platform/SRE on monitoring standards and automation frameworks

Escalation points

• Production incidents exceeding agreed thresholds (time/impact) escalate to:
• On-call incident commander (often SRE)
• Manager of Enterprise Platforms
• Security escalation path if breach suspected
• High-risk changes escalate to CAB and platform leadership.

13) Decision Rights and Scope of Authority

A Senior Database Administrator is a senior individual contributor with meaningful autonomy in operational and technical decisions, bounded by governance and platform strategy.

Can decide independently

• Diagnostic approach and incident mitigation steps within approved emergency procedures.
• Query and index tuning recommendations; execution of tuning changes through standard change process.
• Routine operational actions:
• Restarting services (when safe and approved)
• Adjusting maintenance jobs and schedules
• Updating monitoring thresholds and alert routing
• Backup validation methods and restore testing procedures (aligned to policy).
• Authoring runbooks, standards drafts, and internal training content.

Requires team approval (DBA/Platform team)

• Changes to standard configurations and baseline policies (parameter baselines, patch cadence).
• Introduction of new operational tooling that affects multiple systems.
• Significant changes to HA/replication topology and failover procedures.
• Revisions to on-call runbooks and escalation policies.

Requires manager/director/executive approval

• Budget-impacting decisions:
• Major licensing changes (e.g., Oracle/SQL Server editions), third-party monitoring spend, new vendor contracts.
• Large cloud cost increases or long-term reserved capacity commitments.
• Exceptions to security policy or acceptance of audit risk.
• Major architectural shifts:
• Engine standardization/retirement decisions
• Strategic migration initiatives that impact business timelines
• Staffing changes, hiring, and changes to support coverage models.

Authority areas (typical)

• Architecture authority: Influences and recommends; final approval typically with Enterprise Architecture/Platform leadership.
• Vendor authority: Can manage support cases and recommend vendors; procurement approval usually higher-level.
• Delivery authority: Can block or defer high-risk changes if operational readiness criteria are not met (often through change governance).
• Compliance authority: Owns evidence production and control implementation within DB domain; policy ownership often with Security/GRC.

14) Required Experience and Qualifications

Typical years of experience

• 7–12+ years in database administration, database engineering, or platform operations, with at least 3–5 years supporting production, business-critical systems.
• Experience expectations may skew higher in highly regulated or heavily legacy environments.

Education expectations

• Bachelor’s degree in Computer Science, Information Systems, Engineering, or equivalent experience.
• Equivalent experience is commonly accepted if the candidate demonstrates depth in production operations and reliability.

Certifications (relevant; not always required)

Common / valuable (context-dependent): – Microsoft: Azure Database Administrator Associate (or broader Azure certs) – Optional – AWS: Solutions Architect Associate/Professional or specialty equivalents – Optional – Oracle OCP (Oracle Certified Professional) – Context-specific – Security-oriented certifications (e.g., Security+, CISSP) – Optional (more valuable in regulated orgs)

Prior role backgrounds commonly seen

• Database Administrator (mid-level)
• Systems Administrator / Infrastructure Engineer with DB specialization
• SRE/DevOps engineer with strong database operations exposure
• Database Developer / Data Engineer with production DBA responsibilities (less common but possible)

Domain knowledge expectations

• Software/IT enterprise context:
• ITIL/change management exposure
• Production readiness discipline
• Understanding of application architecture and how services interact with databases
• Industry specialization is not mandatory, but candidates should adapt to:
• Data classification and retention requirements
• Audit controls and evidence collection

Leadership experience expectations (Senior IC)

• Demonstrated technical leadership:
• Leading incidents and postmortems
• Mentoring others
• Driving standards adoption across teams
• People management is not required, but may be a plus if the organization expects informal team leadership.

15) Career Path and Progression

Common feeder roles into this role

• Database Administrator (DBA)
• Database Engineer
• Infrastructure/Systems Engineer (with DB focus)
• SRE/DevOps Engineer (with strong DB ops experience)

Next likely roles after this role

• Lead Database Administrator / DBA Team Lead (senior IC or player-coach, depending on org)
• Principal Database Engineer / Database Architect (platform architecture, standards, modernization leadership)
• Site Reliability Engineer (Databases) / Database Reliability Engineer (DBRE) (SLOs, automation, reliability engineering)
• Platform Engineering Lead (Data Platforms) (broader platform ownership, possibly management track)
• Infrastructure Engineering Manager / Enterprise Platforms Manager (management track)

Adjacent career paths

• Security engineering specialization (database security, IAM, compliance automation)
• Cloud platform specialization (cloud infrastructure, managed services governance)
• Data platform engineering (broader scope including streaming/warehouses—context-specific)
• Performance engineering (application + database end-to-end)

Skills needed for promotion (Senior DBA → Lead/Principal)

• Stronger architectural ownership:
• Multi-region DR designs
• Standardization across many teams
• Technology lifecycle and roadmap leadership
• Advanced automation and platform product thinking:
• Self-service capabilities
• Policy-as-code compliance
• Reduced toil and improved developer experience
• Broader influence:
• Consistent partnership with engineering leadership
• Quantified impact (reliability improvements, cost savings, delivery acceleration)

How this role evolves over time

• Moves from instance-level management to platform-level outcomes:
• Fewer manual interventions; more automation and guardrails
• More time spent on roadmap, standards, and proactive performance work
• Increasing emphasis on:
• Cloud governance and cost optimization
• Compliance automation and continuous controls monitoring
• Cross-team enablement rather than ticket-driven execution

16) Risks, Challenges, and Failure Modes

Common role challenges

• Competing priorities: Incidents, maintenance, and project work collide; without clear prioritization, strategic work stalls.
• Legacy complexity: Older engines/versions with limited automation and fragile upgrade paths.
• Cross-team dependencies: Performance issues often originate in application code or workload patterns; requires influence and partnership.
• Change risk: Schema changes and parameter changes can have high blast radius.
• Noise and alert fatigue: Poorly tuned monitoring wastes time and hides real issues.
• Security vs usability tension: Strict controls can slow delivery if workflows aren’t streamlined.

Bottlenecks

• DBA as a ticket queue gatekeeper (anti-pattern): every schema change, index, or access request requires manual DBA action.
• Single points of failure: only one person knows key systems or recovery steps.
• Unclear ownership: databases owned by “everyone and no one,” causing delays in decision-making and accountability.

Anti-patterns

• Backups exist but restores are never tested.
• DR plans are documents only; no rehearsals or evidence.
• Over-indexing or reactive tuning without measuring outcomes.
• “Hero culture” incident response: untracked, undocumented emergency changes.
• Poor separation of duties: broad admin rights shared across many users.
• Upgrades deferred indefinitely until forced by outage or security incident.

Common reasons for underperformance

• Limited depth in diagnosing performance issues (can’t interpret plans/waits/locks).
• Weak operational discipline: inconsistent change process, incomplete documentation.
• Over-reliance on GUI tools; inability to automate or script.
• Communication gaps during incidents: unclear ETAs, lack of stakeholder management.
• Inflexibility: applying one-engine assumptions incorrectly to another engine.

Business risks if this role is ineffective

• Increased downtime and slow performance impacting customers and revenue.
• Data loss or inability to recover within required timelines.
• Audit failures, security breaches, or regulatory penalties due to weak access controls/logging.
• Higher infrastructure and licensing costs due to lack of capacity governance.
• Slower engineering velocity because database changes become unpredictable and risky.

17) Role Variants

This role is consistent across organizations, but scope and emphasis vary meaningfully by context.

By company size

• Small company (or small IT org):
• Broader scope: DBA may also manage infrastructure, DevOps tasks, and some data engineering.
• Less formal governance; more hands-on execution.
• Mid-size:
• Mix of operational ownership and project work (migrations, automation).
• Increasing specialization (separate SRE/security roles), but DBA still bridges many gaps.
• Large enterprise:
• Strong governance (CAB, audit evidence), more role specialization.
• Senior DBA often focuses on Tier-1 platforms, standards, and escalation rather than routine tickets.

By industry

• Regulated (finance, healthcare, public sector):
• Heavier emphasis on controls, evidence, encryption, retention, access reviews.
• More stringent RPO/RTO validation and DR exercises.
• Non-regulated (many SaaS/tech internal IT):
• Faster change cadence; stronger DevOps integration.
• Greater emphasis on automation and developer enablement.

By geography

• Global teams require:
• Follow-the-sun support models (context-specific)
• Clear runbooks and handoff procedures
• Region-specific data residency constraints (where applicable)

Product-led vs service-led company

• Product-led (SaaS/platform engineering):
• Closer integration with CI/CD and SRE practices.
• Focus on performance SLOs, error budgets, and high-velocity release support.
• Service-led/internal IT:
• More ticket-driven; greater focus on stability, change governance, and lifecycle management.

Startup vs enterprise

• Startup:
• Senior DBA may be first dedicated database expert; heavy architecture and tooling setup.
• More greenfield choices; fewer legacy constraints.
• Enterprise:
• Deep legacy and compliance; emphasis on standardization and modernization roadmaps.

Regulated vs non-regulated environment

• Regulated:
• Mandatory controls: PAM, audit trails, encryption, segregation of duties, formal DR tests.
• Non-regulated:
• Controls still important, but implementation may be lighter; more autonomy in tooling and process.

18) AI / Automation Impact on the Role

Tasks that can be automated (now and increasing)

• Provisioning and baseline configuration
• Standard templates (IaC) and automated post-provision checks.
• Backups and verification
• Automated backup monitoring, immutability checks, and scheduled restore tests with evidence artifacts.
• Monitoring and anomaly detection
• Automated alert correlation; anomaly detection for latency, I/O, replication lag.
• Operational hygiene
• Automated index/statistics maintenance (engine-appropriate), vacuum scheduling, log rotation management.
• Access workflows
• Automated provisioning through IAM integration and approval workflows; time-bound access.

Tasks that remain human-critical

• Architecture and tradeoff decisions
• Selecting HA/DR patterns, consistency tradeoffs, and migration strategies aligned to business risk.
• Complex incident judgment
• When to failover vs tune; when to apply emergency changes; balancing speed with safety.
• Root cause analysis and cross-layer reasoning
• Correlating app behavior, deployments, infrastructure saturation, and database internals.
• Stakeholder management
• Communication, expectation setting, and negotiation of priorities and downtime windows.
• Security risk interpretation
• Understanding the intent of controls and adapting implementation without breaking usability.

How AI changes the role over the next 2–5 years

• Faster diagnostics via AI-assisted summarization of logs, query plans, and incident timelines—reducing time to hypothesis.
• More “recommendation engines” for indexing and configuration tuning—requiring DBAs to validate and measure impact (guarding against harmful suggestions).
• Increased expectation that DBAs build and manage automation pipelines, not just runbooks:
• Treat operational work as code
• Continuous compliance checks
• Evidence generation automation for audits
• Senior DBAs increasingly act as platform reliability owners rather than hands-on operators for every request.

New expectations caused by AI, automation, or platform shifts

• Ability to evaluate AI-generated tuning suggestions and test them safely (A/B testing, canaries, rollback).
• Stronger data governance posture as AI adoption increases interest in data access, lineage, and sensitive data controls (even if the DBA is not the data governance owner).
• More emphasis on standardized interfaces:
• API-driven operations
• Self-service provisioning with guardrails
• Strong observability instrumentation

19) Hiring Evaluation Criteria

What to assess in interviews (competency areas)

1. Production operations depth – On-call experience, incident handling, change control discipline.
2. Performance troubleshooting – Ability to use evidence (plans/waits/locks) and propose measured improvements.
3. Backup/restore and DR competence – Practical restore experience; DR test design; RPO/RTO reasoning.
4. Security and governance – Least privilege, auditing, encryption, secrets; ability to operate in audited environments.
5. Automation mindset – Scripting ability; repeatability; infrastructure-as-code awareness.
6. Cross-team communication – Explaining risk and tradeoffs; influencing developers without blocking delivery.
7. Platform thinking – Standardization, documentation quality, scaling support through mechanisms.

Practical exercises or case studies (recommended)

• Case study 1: Incident simulation (90 minutes)
• Provide metrics excerpts (CPU, I/O, lock waits), a slow query sample, and replication lag data.
• Ask candidate to:
  • Triage and form hypotheses
  • Identify immediate mitigations
  • Propose root cause and longer-term fixes
  • Draft stakeholder update in plain language
• Case study 2: DR/backup design
• Given a Tier-1 system with RPO 15 minutes, RTO 1 hour:
  • Propose HA/DR topology
  • Backup retention approach
  • Restore testing plan and evidence approach
• Case study 3: Migration plan
• Plan a major version upgrade or on-prem-to-cloud migration:
  • Cutover steps, rollback plan, validation steps
  • Risk register and communications plan
• Hands-on exercise (optional, role-dependent)
• Query tuning: interpret an execution plan and propose indexing/rewrites; discuss tradeoffs.

Strong candidate signals

• Has led real restores (not just “backups are configured”) and can describe validation steps.
• Speaks in measurable terms: latency percentiles, IOPS, replication lag, error budgets, success rates.
• Uses safe change patterns: maintenance windows, pre-flight checks, expand/contract schema changes.
• Demonstrates calm incident leadership and crisp communication.
• Provides examples of automation that reduced toil and incidents.
• Understands that many “DB problems” are workload problems and can influence application fixes.

Weak candidate signals

• Vague claims without specifics (“improved performance a lot”).
• Treats backups as “set and forget,” no restore testing evidence.
• Over-indexing or random parameter tweaking without measurement.
• Blames application teams rather than partnering with them.
• No experience with production incident response or change governance.

Red flags

• Willingness to run high-risk changes in production without rollback plans.
• Suggests bypassing access controls or sharing privileged credentials.
• Cannot explain RPO/RTO or confuses them.
• Dismisses documentation and runbooks as “non-essential.”
• Does not understand basics of locking, transactions, or replication consistency.

Scorecard dimensions (with suggested weighting)

Dimension	What “meets bar” looks like	Weight
Production operations & incident response	Has handled P1/P2 incidents; structured triage; strong comms	20%
Performance tuning	Can analyze plans/waits/locks; proposes safe, measurable improvements	20%
Backup/restore & DR	Proven restore experience; can design and test DR effectively	20%
Security & compliance	Least privilege, auditing, encryption; understands evidence needs	15%
Automation & tooling	Scripting competence; repeatable operations; monitoring integration	15%
Collaboration & influence	Partners with engineering/SRE; clear communication	10%

20) Final Role Scorecard Summary

Category	Executive summary
Role title	Senior Database Administrator
Role purpose	Ensure enterprise database platforms are available, performant, secure, and recoverable; reduce operational risk through standards and automation; enable engineering delivery safely.
Top 10 responsibilities	1) Own production DB reliability and operations 2) Lead incident response and escalation 3) Design/maintain HA and replication 4) Own backup/restore and DR testing 5) Execute patching/upgrades and lifecycle management 6) Drive performance tuning and query optimization 7) Implement security controls (least privilege, encryption, auditing) 8) Plan capacity and optimize cost/performance 9) Lead migrations and cutovers with rollback plans 10) Create runbooks/standards and mentor others
Top 10 technical skills	1) RDBMS administration (Postgres/SQL Server/MySQL/Oracle) 2) Backup/restore & PITR 3) DR design and testing (RPO/RTO) 4) SQL and query plan analysis 5) Indexing/statistics tuning 6) Locking/concurrency troubleshooting 7) HA/replication/failover patterns 8) Monitoring/observability for DB 9) Security hardening, encryption, auditing 10) Automation scripting (Python/PowerShell/Bash)
Top 10 soft skills	1) Incident leadership 2) Analytical problem solving 3) Risk judgment and change discipline 4) Clear stakeholder communication 5) Ownership mentality 6) Influence without authority 7) Mentorship/coaching 8) Documentation rigor 9) Prioritization under pressure 10) Collaboration across engineering/security/ITSM
Top tools or platforms	PostgreSQL, SQL Server, MySQL/MariaDB (Oracle context-specific); AWS/Azure managed DB (RDS/Aurora/Azure SQL); Datadog/Prometheus/Grafana/CloudWatch/Azure Monitor; ServiceNow; Git; Vault/Secrets Manager/Key Vault; Python/PowerShell/Bash; (Terraform/Ansible optional)
Top KPIs	Availability/SLO attainment; P1/P2 incident rate; MTTD/MTTR; backup success & restore test pass rate; achieved RPO/RTO; replication lag; performance SLO (latency); change success rate; patch compliance; security findings closure time
Main deliverables	Standards/baselines; HA/DR designs and DR test reports; backup/restore policies and evidence; runbooks/playbooks; performance optimization reports; automation scripts/IaC modules (where applicable); dashboards; change plans; training materials
Main goals	30/60/90-day stabilization and standardization; 6-month DR/backup maturity and incident reduction; 12-month upgrade compliance and measurable reliability improvement; long-term shift to automation-first, platform-like database services
Career progression options	Lead DBA/DBA Team Lead; Principal Database Engineer/Database Architect; DBRE/SRE (Databases); Platform Engineering Lead (Data Platforms); Infrastructure/Enterprise Platforms Manager (management track)