A database rarely has just one user. Dozens or thousands of sessions read and change the same data at once, and the database still has to give each of them a correct answer. Transactions & concurrency is about how that works, and what a DBA can tune when it doesn't.
You'll build on the ACID guarantees from Module 01 and focus on isolation: the isolation levels READ COMMITTED, REPEATABLE READ, and SERIALIZABLE, and what each one allows or prevents. From there the module looks at multi-version concurrency control (MVCC), the technique PostgreSQL and many other databases use to let readers and writers work side by side without constantly blocking each other.
With a clear picture of how concurrent work stays safe, you'll be ready for the next module, Backup & Recovery, where you learn how to protect that data and restore it when something goes wrong.
A walkthrough of the READ COMMITTED, REPEATABLE READ, and SERIALIZABLE isolation levels in SQL Server, and how each one keeps transactions isolated from the others.
Hands-on experiments showing how PostgreSQL uses multi-version concurrency control, from hidden row columns and multiple row versions to cleaning up old versions with vacuum.
A university database systems lecture by Andy Pavlo on multi-version concurrency control, for going deeper into how databases let readers and writers work side by side.