How to check your SQL Server version and edition

Updated and tested 14 October 2026

The number in the product name and the number the engine reports are two different things, so answering "which SQL Server is this?" takes a query. SQL Server 2022 reports itself as 16.x. SQL Server 2025 reports 17.x. Here is how to get a real answer out of an instance you can connect to, and out of one you cannot.

SELECT @@VERSION and what it tells you

SELECT @@VERSION;

One row, one long string. An example from a SQL Server 2025 RTM install looks like this:

Microsoft SQL Server 2025 (RTM) - 17.0.1000.7 (X64)
    Enterprise Developer Edition (64-bit) on Windows Server 2019 Standard

Left to right that is the product year, the servicing level in brackets, the four-part build number, the processor architecture, then the edition and the host operating system. Six fields, one string, no separators you can rely on.

"Enterprise Developer Edition" in that line is Developer edition wearing its Enterprise flavour. On a server somebody else built, that is worth noticing, since Developer is not licensed for production. The SQL Server editions differ in more places than the licence terms, and if that distinction is new to you it is twenty minutes well spent before you plan anything around it.

@@VERSION is fine for a person to read. It is awkward in a script, because you end up parsing a string whose layout has shifted between releases. For anything programmatic, use SERVERPROPERTY.

SERVERPROPERTY for version, edition and update level

SELECT SERVERPROPERTY('MachineName') AS ComputerName,
       SERVERPROPERTY('ServerName') AS InstanceName,
       SERVERPROPERTY('Edition') AS Edition,
       SERVERPROPERTY('ProductVersion') AS ProductVersion,
       SERVERPROPERTY('ProductLevel') AS ProductLevel,
       SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel;

MachineName returns the computer name. ServerName returns the instance name as the engine currently sees it. Edition returns the edition string on its own, so to check SQL Server edition and nothing else you can select that single column. ProductVersion returns the build, something like 17.0.4075.5. ProductLevel returns RTM, SPn or CTPn. ProductUpdateLevel returns the cumulative update as a string, CU8 for instance, or NULL when no cumulative update has been applied, which includes an RTM build carrying only a GDR.

The SERVERPROPERTY reference lists a lot more properties than those six, most of which you will never need. ProductUpdateLevel is the one worth putting into your habits. The usual routine for identifying a CU is copying a build number into a search box and hunting through a table of hundreds of rows; this column just tells you. Go to the build tables when it comes back NULL, or when you need a release date.

SQL Server version numbers and product names

• 14.x is SQL Server 2017
• 15.x is SQL Server 2019
• 16.x is SQL Server 2022
• 17.x is SQL Server 2025

There is no SQL Server 2023 and no SQL Server 2024. The major number is what matters for driver support questions, database compatibility levels and the file paths further down this page.

That three-year gap is odd on its own terms. Microsoft had been shipping every two years or so, and the numbering has wandered before now: 2008 R2 is 10.50 and not 11, which broke a lot of scripts that compared version strings as decimals. None of which helps you read a build off a live server. It is just the shape of the list.

MSSQL Server 2022 is, I'd guess, still where most production estates are sitting.

Map a build number to a cumulative update

Microsoft's build tables are the source of truth when ProductUpdateLevel is NULL, or when you are reading a build out of a log file with no live connection to query. There is an index page pointing at the latest update for each supported version, and behind it a per-version list carrying every build with its KB article and its release date, like the one for SQL Server 2025.

Match on the full four-part build, since the first two parts only identify the major version. A build that does not appear in the CU list at all usually means the instance is on the security-only update branch, which has its own build numbers and its own release cadence.

Check the MSSQL version without connecting to the instance

From the error log

The first lines the engine writes at startup are the version banner, the same string @@VERSION hands back. On Linux the log sits at /var/opt/mssql/log/errorlog and it is UTF-16LE, so if head gives you spaced-out nonsense, convert it on the way through:

sudo iconv -f UTF-16LE -t UTF-8 /var/opt/mssql/log/errorlog | head -n 5

On Windows the log is at C:\Program Files\Microsoft SQL Server\MSSQL17.MSSQLSERVER\MSSQL\Log\ERRORLOG, with MSSQL16 in the path for SQL Server 2022. That folder name is a version check on its own: MSSQL17 means 2025, MSSQL16 means 2022 and you did not need to open anything.

From the Linux package manager

apt list --installed mssql-server
dpkg -l mssql-server

Either one gives you the package version in the shape 17.0.4075.5-1, which is the build number with a package revision appended. It works with the service stopped, which is usually the situation where you need it. I type the dpkg one out of habit, mostly because its columns stay readable in a narrow terminal.

Straight after installing SQL Server on Ubuntu this is also the quickest confirmation that the repository handed you the release you expected and not an older one sitting in a stale mirror.

On Windows

The Programs list shows "Microsoft SQL Server 2025 (64-bit)" with a version number, which is a rough answer and not the engine's current build. SQL Server Configuration Manager is the better route. It is an MMC snap-in that newer versions of Windows might not list as an app, so run SQLServerManager17.msc for SQL Server 2025 or SQLServerManager16.msc for 2022, both under C:\Windows\SysWOW64\. The filename tells you the major version before the window opens, so if 17 does not exist and 16 does, you are on 2022.

If SQL Server Management Studio is already open, forget all of that. Object Explorer prints the build next to the server name at the top of the tree.

Check the version from another machine with sqlcmd

sqlcmd -S host,1433 -U sa -P '<password>' -C -Q "SELECT @@VERSION;"

The -C is doing real work there. In mssql-tools18 the -N flag defaults to mandatory encryption, a breaking change from SQL Server 2022 and earlier where it defaulted to optional, so an instance presenting its own self-signed certificate needs -C to trust it or -No to make encryption optional again. Drop -Q and you get an interactive session.

Remote connection problems are a different hunt entirely, and that is what you have if the connection itself is failing and not the query.

SQL Server support dates and missing updates

Version numbers mostly matter because of what is still supported. The lifecycle pages carry the authoritative dates and those dates do shift occasionally, so treat the list below as a snapshot:

• SQL Server 2017 is in extended support until 13 October 2027.
• SQL Server 2019 left mainstream support on 1 March 2025 and runs on extended support until 9 January 2030.
• SQL Server 2022 has mainstream support until 12 January 2028 and extended until 12 January 2033.
• SQL Server 2025 has mainstream support until 7 January 2031 and extended until 7 January 2036.

I looked the 2017 date up while writing this. Four rows and none of them stay in my head.

Extended support means security updates and nothing else. No new cumulative updates, no non-security bug fixes. A SQL Server 2019 instance today is already in that position, collecting security patches while every functional fix Microsoft ships lands on 2022 and 2025 only. Fine for something stable you have stopped changing. Uncomfortable if you are chasing a bug that is already closed upstream.

Check if a cumulative update is missing

Compare ProductUpdateLevel against the latest CU on Microsoft's index for your major version. If yours says CU12 and the index lists CU15, you are three behind, and because cumulative updates are cumulative you install the newest one and skip everything in between. If ProductUpdateLevel comes back NULL on a 2019 or 2022 instance, that instance has never had a cumulative update applied, which is a finding worth acting on the same week you make it.

Run the SERVERPROPERTY query against every SQL Server you own and drop the output into a spreadsheet. Ten minutes across a small estate, and it is how people find the 2017 box nobody remembers building and nobody has patched since.