How to Check Your SQL Server Version (Multiple Methods Explained)

Knowing which version of SQL Server you're running isn't just useful trivia — it affects compatibility with applications, determines which features are available, and matters enormously for patching and security. Whether you're a DBA troubleshooting an issue or a developer confirming an environment, there are several reliable ways to check.

Why SQL Server Version Numbers Are More Complex Than They Look

SQL Server doesn't use simple version names like "2019" or "2022" alone. Under the hood, it uses a multi-part build number — something like 15.0.2000.5 — where each segment carries specific meaning:

• Major version — the broad release (e.g., 15 = SQL Server 2019)
• Minor version — usually 0 for SQL Server
• Build number — identifies the specific Cumulative Update (CU) or Service Pack installed
• Revision — a fine-grained patch identifier

This means two servers both running "SQL Server 2019" can behave differently if one has applied recent cumulative updates and the other hasn't. The full build number tells the complete story.

Method 1: Using a T-SQL Query 🖥️

The fastest and most reliable method — especially for developers and DBAs — is running a query directly against the server.

Option A — SELECT @@VERSION

SELECT @@VERSION; 

This returns a long string containing the SQL Server edition, version number, operating system details, and build date. It's human-readable but not always easy to parse programmatically.

Option B — SERVERPROPERTY()

SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion, SERVERPROPERTY('ProductLevel') AS ProductLevel, SERVERPROPERTY('ProductUpdateLevel') AS CumulativeUpdate, SERVERPROPERTY('Edition') AS Edition; 

This is cleaner for automation. ProductVersion gives you the numeric build string, ProductLevel tells you the Service Pack (or RTM for original release), and ProductUpdateLevel shows the Cumulative Update identifier if one is installed.

Method 2: SQL Server Management Studio (SSMS)

If you prefer a GUI approach, SQL Server Management Studio surfaces version information in two places:

1. Connection dialog — when you connect to an instance, the server name field sometimes displays the version in the tooltip or connection properties.
2. Object Explorer — right-click the server name at the top of the Object Explorer pane and select Properties. The General page shows the version, edition, and platform clearly.

This method is accessible to users who aren't comfortable writing queries, but it requires SSMS to be installed and a live connection to the instance.

Method 3: Windows Registry or Command Line

For scenarios where you can't connect to the SQL Server instance directly — perhaps it won't start, or you're doing pre-installation checks — Windows itself stores version information.

Using the Registry: Navigate to: HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL Server[InstanceName]Setup

Look for the Version key. This shows what was installed, though it may not always reflect post-installation patches accurately.

Using the command line:

SQLCMD -S ServerName -Q "SELECT @@VERSION" 

This works from a command prompt when SSMS isn't available. You'll need appropriate permissions and the SQLCMD utility installed.

Using PowerShell:

Invoke-Sqlcmd -Query "SELECT @@VERSION" -ServerInstance "ServerName" 

Useful in automated scripts or environments managed through PowerShell remoting.

Method 4: Windows Programs & Features or Apps

If SQL Server is installed locally and you just need a rough version check, you can look in Control Panel → Programs → Programs and Features (or Settings → Apps on Windows 10/11). The SQL Server entry typically shows the major version year in the program name.

This won't give you the specific build number or cumulative update level — just enough to confirm which major release is installed.

Reading the Version Number: Quick Reference Table

The build number within each major version tells you how current your patching is. Microsoft publishes a full list of SQL Server builds, and comparing your build number against that list reveals whether you're behind on Cumulative Updates.

Variables That Affect Which Method Works for You

Not every method is available in every situation. A few factors shape which approach makes sense:

• Access level — querying via T-SQL requires login credentials with at least public role access; registry access requires local Windows permissions
• SQL Server edition — Express, Developer, Standard, Enterprise, and Azure SQL Database each surface version data slightly differently
• Whether the instance is running — T-SQL methods only work against a live, reachable instance
• Remote vs. local — remote instances may need network access, firewall rules, or SQLCMD configured with the right connection string
• Automation needs — if you're scripting version checks across many servers, SERVERPROPERTY() or PowerShell are more practical than SSMS

What the Edition and Patch Level Actually Mean 🔍

Version and edition are separate things. Version tells you the release year and build. Edition (Express, Standard, Enterprise, Developer) tells you the feature set and licensing tier. A fully patched SQL Server 2019 Express and a fully patched SQL Server 2019 Enterprise will return the same ProductVersion number but very different Edition values — and they'll have very different capability ceilings.

Similarly, two servers on the same major version but different cumulative update levels may behave differently with certain queries, have different bug fixes applied, and present different security exposure surfaces.

The method that gives you the most complete picture is SERVERPROPERTY() in T-SQL, since it separates out version, level, edition, and update level into distinct, queryable values.

Which of these methods is practical depends on what kind of access you have, whether you're checking one server or many, and how much detail you actually need for the task in front of you.