How to Become a Database Administrator: Best DBA Books to Read, in Order
This curriculum takes an intermediate learner from solid SQL fundamentals through the core DBA disciplines — performance tuning, backup/recovery, and security — before finishing with certification-oriented and hands-on practice resources. Each stage builds the vocabulary and mental models needed for the next, so skipping ahead is discouraged; a concept introduced early (e.g., query execution plans) becomes a tool used heavily in later stages.
SQL Mastery & Relational Foundations
IntermediateAchieve confident, fluent SQL writing and deeply understand how relational databases store, index, and retrieve data — the bedrock every DBA skill depends on.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (including active practice sessions)
- SQL SELECT, JOIN, subquery, and aggregation syntax and execution semantics
- Relational algebra foundations: sets, relations, normalization, and ACID properties
- Index structures (B-tree, hash) and how query optimizers use them to choose execution plans
- Transaction isolation levels and locking mechanisms that prevent data corruption
- Common SQL antipatterns (N+1 queries, implicit type conversions, missing indexes) and their performance/correctness costs
- Query optimization: reading execution plans, identifying bottlenecks, and rewriting for efficiency
- Schema design trade-offs: normalization vs. denormalization, constraints, and referential integrity
- Explain the difference between INNER JOIN, LEFT JOIN, and FULL OUTER JOIN; when would you use each and why?
- What is a subquery, and how does it differ from a JOIN? When is one preferable to the other?
- How do indexes improve query performance, and what is the cost of maintaining them?
- What are the four ACID properties, and how do transaction isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) protect against anomalies?
- Describe three SQL antipatterns from the Karwin book and explain why each is problematic and how to refactor it.
- How do you read and interpret a query execution plan to identify performance bottlenecks?
- What is database normalization, and why might you intentionally denormalize a schema?
- Complete all hands-on exercises in 'Learning SQL' chapters 1–15, using a real database (PostgreSQL, MySQL, or SQLite) to write and execute queries.
- Build a normalized schema for a realistic domain (e-commerce, library, or HR system) with at least 5 tables, primary keys, foreign keys, and constraints; then write 20+ queries (SELECT, JOIN, GROUP BY, subqueries) against it.
- Identify and refactor 5 SQL antipatterns from 'SQL Antipatterns' by rewriting them for correctness and performance; measure query time before and after.
- Analyze execution plans for 10 slow queries using EXPLAIN (PostgreSQL) or EXPLAIN PLAN (MySQL/Oracle); add indexes and rewrite queries to reduce execution time by at least 50%.
- Design and implement a transaction scenario (e.g., bank transfer, inventory update) that demonstrates isolation levels and locking; test it under concurrent load.
- Write a technical summary (500–800 words) comparing normalized vs. denormalized schemas for a specific use case, with trade-off analysis.
Next up: This stage equips you with the SQL fluency and relational theory needed to design schemas, optimize queries, and understand how databases execute your code—essential prerequisites for the next stage on backup/recovery, replication, and high-availability architecture where you'll apply these foundations to protect and scale production systems.
A clean, thorough treatment of SQL from SELECT through advanced joins and subqueries; ideal for solidifying intermediate knowledge before moving into DBA-specific territory.
Teaches correct schema design and query patterns by dissecting common mistakes — essential for a DBA who must review and fix others' work.
Database Internals & Architecture
IntermediateUnderstand how a database engine actually works under the hood — storage engines, indexes, transactions, and locking — so that every tuning or recovery decision is grounded in first principles.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (mix of dense technical content and hands-on practice)
- Storage engines and data structures: B-trees, LSM trees, hash tables, and how they trade off read/write performance and space efficiency
- Page-based storage model: how databases organize data into fixed-size blocks, manage memory buffers, and perform I/O operations
- Indexing strategies: single-column and composite indexes, index selection, and how query planners use indexes to optimize execution
- Transaction fundamentals: ACID properties, isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE), and their real-world implications
- Locking and concurrency control: row-level vs. table-level locks, deadlock detection, lock escalation, and multi-version concurrency control (MVCC)
- Recovery and durability: write-ahead logging (WAL), checkpoints, crash recovery, and ensuring data consistency after failures
- Query execution and optimization: how the query planner builds execution plans, cost estimation, and join algorithms (nested loop, hash join, sort-merge)
- MySQL-specific internals: InnoDB architecture, storage format, buffer pool management, and how MySQL's design differs from other database engines
- Explain the trade-offs between B-tree and LSM tree storage engines. When would you choose one over the other for a given workload?
- What is the page-based storage model, and how does understanding it help you optimize database performance and tune buffer pool settings?
- Describe the difference between READ COMMITTED and REPEATABLE READ isolation levels, and explain what anomalies each one prevents or allows.
- How do write-ahead logging (WAL) and checkpoints work together to ensure durability and enable crash recovery?
- What is MVCC (multi-version concurrency control), and how does it reduce lock contention compared to traditional locking?
- Walk through the steps a query optimizer takes to build an execution plan, including how it estimates costs and chooses between join algorithms.
- Explain InnoDB's clustered index design and how it affects both query performance and storage layout in MySQL.
- What causes deadlocks in a multi-threaded database, and what strategies can you use to detect and prevent them?
- Read Part I of 'Database Internals' (Chapters 1–3) and create a visual comparison chart of B-trees, LSM trees, and hash tables, noting their strengths and weaknesses for different access patterns.
- Set up a MySQL instance locally and use EXPLAIN and EXPLAIN FORMAT=JSON to analyze query execution plans; identify which indexes are being used and why the optimizer chose a particular join strategy.
- Write a test script that creates transactions at different isolation levels (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) and observe which anomalies (dirty reads, non-repeatable reads, phantom reads) occur at each level.
- Study InnoDB's buffer pool behavior by monitoring the buffer pool hit ratio using SHOW ENGINE INNODB STATUS; adjust the pool size and measure the impact on query performance.
- Implement a simple B-tree insertion and search algorithm in a language of your choice (Python, Java, or C++) to understand how page splits and rebalancing work.
- Create a multi-threaded application that performs concurrent inserts and updates on the same table, then use MySQL's lock monitoring tools (SHOW PROCESSLIST, SHOW OPEN TABLES) to identify lock contention and deadlocks.
- Read the 'Recovery and Durability' chapter in 'Database Internals' and trace through a crash recovery scenario step-by-step, documenting how WAL and checkpoints restore consistency.
- Analyze the InnoDB storage format by examining the .ibd file structure using tools like innodb_space; understand how clustered indexes and secondary indexes are physically stored.
Next up: Mastering database internals equips you with the mental models needed to diagnose performance bottlenecks, design efficient schemas, and make informed decisions about indexing and configuration—skills that directly enable the next stage of advanced tuning and optimization.
Demystifies storage engines, B-trees, LSM trees, and distributed consensus; gives the mental model needed to reason about performance and durability at a deep level.
Walks through a real, widely-deployed RDBMS codebase, reinforcing the abstract concepts from Petrov with concrete engine-level detail.
Performance Tuning
IntermediateRead and interpret execution plans, design effective indexes, tune queries and server configuration, and diagnose slow workloads systematically.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day with hands-on lab time (2–3 hours per week minimum)
- How to read and interpret execution plans (EXPLAIN output, cost analysis, and row estimates) to identify bottlenecks
- Index design principles: B-tree structure, selectivity, covering indexes, and when indexes help or hurt performance
- Query optimization techniques: join order, predicate pushdown, avoiding full table scans, and rewriting inefficient queries
- Server configuration tuning: buffer pools, query cache (if applicable), connection management, and resource allocation
- Systematic diagnosis methodology: establishing baselines, isolating slow queries, measuring impact of changes, and avoiding premature optimization
- Access path selection: how the optimizer chooses between sequential scans, index seeks, and index range scans
- Common performance anti-patterns: N+1 queries, missing indexes, poor join strategies, and suboptimal data types
- How do you read a MySQL EXPLAIN plan, and what do key columns like 'type', 'key', 'rows', and 'Extra' tell you about query performance?
- What is the difference between a covering index and a non-covering index, and when should you use each?
- How do you systematically identify which queries are causing performance problems in a production workload?
- What are the main server configuration parameters that affect query performance, and how do you tune them for your workload?
- How does the query optimizer decide between using an index and performing a full table scan, and what factors influence this decision?
- What are the most common SQL anti-patterns that cause poor performance, and how do you rewrite them?
- Set up a local MySQL instance and create a sample database with 100K+ rows; run EXPLAIN on 10 different queries and document what each execution plan tells you
- Design and implement 5 indexes on a poorly performing table; measure query execution time before and after, and explain why each index helps (or doesn't)
- Take a slow query (>1 second) from a real workload or sample dataset; rewrite it using join optimization, predicate pushdown, or covering indexes; measure the improvement
- Analyze a production slow query log (or simulate one); identify the top 5 slowest queries, diagnose root causes using EXPLAIN, and propose index or query rewrites
- Configure MySQL server parameters (buffer pool size, query cache, max connections) for a specific workload scenario; benchmark before and after changes
- Write a diagnostic script or query that identifies missing indexes, unused indexes, and N+1 query patterns in a sample application
Next up: This stage equips you with the tactical skills to diagnose and fix individual query and server bottlenecks; the next stage will likely expand to architectural decisions—such as replication, sharding, caching strategies, and capacity planning—that optimize performance at scale across distributed systems.
The canonical DBA performance reference for MySQL/MariaDB — covers indexing strategy, query optimization, schema design, and server tuning in production depth.
Platform-agnostic, laser-focused on index internals and execution plans; read after High Performance MySQL to generalize the tuning mindset across any RDBMS.
Backup, Recovery & Security
ExpertDesign and test backup strategies, execute point-in-time recovery, harden database servers, manage users and privileges, and audit access — the operational core of a professional DBA role.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (mix of dense technical content and hands-on labs)
- Backup architecture and strategies: full, incremental, differential, and snapshot-based approaches; choosing the right mix for RPO/RTO requirements
- Recovery mechanisms: point-in-time recovery (PITR), crash recovery, media recovery, and testing recovery procedures to ensure they actually work
- Database hardening: securing the database server at the OS and database levels, disabling unnecessary services, applying patches, and configuring secure defaults
- User and privilege management: principle of least privilege, role-based access control (RBAC), password policies, and preventing privilege escalation
- Audit and logging: enabling comprehensive audit trails, monitoring access patterns, detecting suspicious activity, and maintaining audit logs for compliance
- Common attack vectors and vulnerabilities: SQL injection, weak authentication, default credentials, unpatched systems, and privilege abuse
- Security testing and validation: penetration testing basics, vulnerability scanning, and verifying that security controls actually prevent unauthorized access
- Operational resilience: designing systems that can survive failures, recover quickly, and maintain security posture during incidents
- What is the difference between RPO and RTO, and how do they drive your choice of backup strategy (full vs. incremental vs. differential)?
- Walk through the steps of executing a point-in-time recovery from transaction logs; what can go wrong and how do you verify success?
- Describe a complete backup and recovery testing plan: what should you test, how often, and what constitutes a successful test?
- What are the key hardening steps for a production database server, and why is each one important for preventing unauthorized access?
- How would you design a privilege model for a database with multiple application teams, ensuring each team has only the access it needs?
- What audit events should you log and monitor to detect a privilege escalation attack or unauthorized data access?
- Explain how SQL injection works and what database-level and application-level controls prevent it.
- How do you balance security controls with operational performance and usability?
- Set up a full backup strategy for a test database: configure full, incremental, and differential backups on a schedule; document RPO and RTO targets.
- Execute a point-in-time recovery from transaction logs: corrupt or delete data, then recover to a specific timestamp; verify data integrity.
- Design and run a backup recovery test: restore a backup to a non-production environment, validate that all data and schemas are intact, and time the recovery.
- Harden a database server: disable unnecessary services, apply security patches, set strong password policies, enable encryption at rest and in transit, and document each step.
- Create a role-based privilege model: define roles (e.g., app_read, app_write, dba_admin), assign minimal privileges to each, and test that users can only perform intended actions.
- Enable and configure audit logging: set up comprehensive audit trails for DDL, DML, and access events; generate and review audit reports.
- Perform a privilege escalation test: attempt to escalate from a low-privilege user to admin; document what succeeded or failed and why.
- Conduct a SQL injection test: write a vulnerable query, craft an injection payload, verify it works, then implement parameterized queries or prepared statements to block it.
Next up: This stage equips you with the operational discipline and security mindset to protect databases in production; the next stage will likely focus on performance tuning, capacity planning, or advanced architecture topics, where you'll apply these hardened, resilient foundations to optimize for scale and business impact.
The definitive guide to backup architecture, media management, and recovery planning across multiple platforms; establishes the discipline before diving into database-specific tooling.
Covers real attack vectors against major database platforms, teaching DBAs to think like an attacker in order to harden configurations, patch vulnerabilities, and audit privileges effectively.
Certification, Administration & Practice
ExpertConsolidate all prior knowledge into exam-ready, hands-on DBA competency — covering administration workflows, automation, and the structured knowledge required for industry certifications.
▸ Study plan for this stage
Pace: 8–10 weeks, ~40–50 pages/day (accounting for hands-on lab work and configuration exercises)
- PostgreSQL architecture: processes, memory structures, and configuration parameters for production optimization
- Installation, initialization, and cluster management across different operating systems and deployment scenarios
- User authentication, role-based access control (RBAC), and privilege management for security hardening
- Backup and recovery strategies: full, incremental, and point-in-time recovery (PITR) using pg_dump, pg_basebackup, and WAL archiving
- Replication and high availability: streaming replication, logical replication, and failover mechanisms
- Performance tuning: query optimization, index strategies, vacuum/autovacuum configuration, and monitoring
- Automation and scripting: PostgreSQL administration through scripts, cron jobs, and monitoring tools
- Troubleshooting and log analysis: interpreting PostgreSQL logs, identifying bottlenecks, and resolving common issues
- What are the key PostgreSQL processes (postmaster, backend, WAL writer, autovacuum) and how do they interact in a running cluster?
- How do you configure PostgreSQL for production use, including memory allocation, connection limits, and checkpoint settings?
- What is the difference between physical and logical replication, and when would you use each in a production environment?
- Describe a complete backup and recovery strategy using pg_basebackup and WAL archiving to achieve point-in-time recovery.
- How do you diagnose and resolve performance issues using PostgreSQL logs, EXPLAIN ANALYZE, and system monitoring?
- What are the best practices for user authentication, role hierarchy, and privilege delegation in PostgreSQL?
- Install PostgreSQL from source on Linux; configure postgresql.conf for a production workload (shared_buffers, effective_cache_size, work_mem, maintenance_work_mem) and verify settings with SHOW commands
- Set up a multi-user environment with role hierarchy: create superuser, regular users, read-only roles, and application accounts; test privilege inheritance and revocation
- Configure and execute a full backup using pg_dump; restore it to a new cluster and verify data integrity
- Set up streaming replication: create a primary and standby server, configure WAL archiving, and test failover scenarios
- Enable autovacuum monitoring; run VACUUM ANALYZE on a test table; analyze the impact on query performance using EXPLAIN ANALYZE before and after
- Create a monitoring script that checks PostgreSQL cluster health (connection count, cache hit ratio, replication lag) and logs results to a file; schedule it with cron
Next up: This stage transforms you from a knowledgeable user into a certified, production-ready DBA by anchoring theoretical understanding in hands-on administration, automation, and troubleshooting—preparing you to manage enterprise PostgreSQL environments and pursue formal DBA certifications.
A practical, hands-on administration guide for PostgreSQL — an open-source platform widely used for DBA practice labs and increasingly demanded by employers alongside commercial databases.
Discussion
Keep reading
Paths that share books, cover the same subject, or open a related topic.
