Don't Panic — Microsoft SQL Server

Microsoft SQL Server is a relational database management system: a place where applications keep structured data, ask questions in T-SQL, and expect changes to behave themselves. That last expectation is doing considerable work. Databases are where an application puts the facts it would prefer not to lose, which is a rather more demanding job than keeping a spreadsheet in a heroic folder.

The central arrangement is reassuringly nested. An instance is the running Database Engine. It can host several databases. Each database holds tables, views, stored procedures, users, and other objects. A schema groups those objects and gives them names that do not have to collide in a small, bureaucratic heap.

The thing to remember is the transaction. It is one business change, treated as all-or-nothing. SQL Server describes this with ACID: atomicity, consistency, isolation, and durability. In practice, this means a change should not stop halfway through because two people arrived at the same row with confident expressions and incompatible plans.

SQL Server is not only a query engine. The Database Engine checks access, stores and processes data, and carries the operational obligations with it. A login identifies access to the instance; a database user and a role shape access inside a database. Roles keep permissions understandable as people change, which is unusually considerate behavior for software.

Recovery has two neighboring but different chores. Backups and restores recover data. High availability reduces service interruption. Neither substitutes for the other, and a backup that has never been restored is an optimistic file with excellent posture. A tested restore is the useful proof.

SQL Server can run on Windows, Linux, containers, and virtual machines. Azure SQL Database and Azure SQL Managed Instance use the same Database Engine family with managed-service boundaries. The surprise is that changing where it runs does not remove the need to understand databases, transactions, security, and recovery; it changes who owns more of the platform work.

Read the Intro for the full architecture and vocabulary. Use Slides when the hierarchy and operational split need a compact map. Keep the Cheatsheet nearby when login, user, role, backup, and high-availability terms start assembling themselves into an unhelpful cloud. The Reference tab then takes you from the product map through database objects, recovery, security, and performance work.