Updated and tested 6 October 2026
MSSQL is Microsoft SQL Server. One product, two names, and Microsoft leans on the short one as heavily as anybody: the Linux service is mssql-server, the install sits in /opt/mssql and the container image reads MSSQL_SA_PASSWORD and MSSQL_PID. Its Visual Studio Code extension carries the MSSQL name too. SQL Server is the name on the licence and across learn.microsoft.com, while MSSQL is the internal short name that leaked out of the plumbing and into everyone's search bar.
What you get under either name is a relational database engine that speaks T-SQL, Microsoft's dialect of SQL, with procedural extensions and a long tail of behaviour that differs from PostgreSQL and MySQL in ways nobody warns you about until a query returns the wrong number. It runs on Windows and on Linux, it ships in editions with hard caps on memory and cores. The current release is SQL Server 2025.
This is the overview I wanted when I inherited my first MSSQL box: what version am I on, where does it live, why won't it let me connect and which parts of the dialect are going to surprise me. Some sections here are long because the detail matters and there's nowhere else to put it. Others are a paragraph, because a sibling article already does the job properly.
MSSQL server versions and lifecycle dates
Version numbers come in two flavours and you need both. The marketing year (2019, 2022, 2025) is what people say out loud. The internal major version is what @@VERSION prints, what the log folder is named and what half the tooling keys off. The map is short enough to memorise: 2017 is 14.x, 2019 is 15.x, 2022 is 16.x and 2025 is 17.x. That's why a default 2022 instance on Windows logs into MSSQL16.MSSQLSERVER and why the Configuration Manager snap-in for 2025 is SQLServerManager17.msc.
SQL Server 2025 went GA on 18 November 2025 with RTM build 17.0.1000.7, and it earns the year in its name. The two headline additions are a native vector data type (1 to 1,998 dimensions, float32 by default) with VECTOR_DISTANCE for exact k-nearest-neighbour search, and a set of regular expression functions: REGEXP_LIKE, REGEXP_REPLACE, REGEXP_SUBSTR, REGEXP_INSTR, REGEXP_COUNT, REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE.
Both come with caveats that matter more than the announcement. The approximate vector index and VECTOR_SEARCH are explicitly in preview. REGEXP_LIKE and the two table-valued functions, REGEXP_MATCHES and REGEXP_SPLIT_TO_TABLE, need database compatibility level 170 (the other scalar ones run at any level), which catches out people who upgrade an instance, run REGEXP_LIKE and get told the function doesn't exist. The engine behind them is RE2, so there are no backreferences and no lookaround. Don't promise your team PCRE parity.
Microsoft publishes the dates on the SQL Server 2025 lifecycle page and equivalents for each release, and the ones to have in a calendar are these. SQL Server 2022 is still the version you'll meet most often in the wild and it's fine, with mainstream support to 12 January 2028 and extended support to 12 January 2033. SQL Server 2019 lost mainstream support on 1 March 2025, so no more design changes and no new features, with extended support carrying security fixes to 9 January 2030. SQL Server 2017 runs out entirely on 13 October 2027.
On new installs in 2026 I don't hedge: install 2025. The support window is three years longer than 2022's, the Linux support matrix is newer and Express got a cap increase that changes what you can do without paying. The one reason to install 2022 instead is a third-party application whose vendor certifies 2022 and not 2025, which is a constraint I've hit more than once and lost the argument every time.
When the engine won't start you can't query it, which is why the registry and command-line routes in our walkthrough on how to check your SQL Server version and edition sit alongside the T-SQL ones. For what's on a machine right now, don't guess from folder names. SERVERPROPERTY('ProductLevel') and SERVERPROPERTY('ProductUpdateLevel') will tell you RTM versus CU. Cumulative updates ship monthly in a release's first year and every two months after that, so any build number printed in an article (including this one) is stale within weeks, and for a build list worth bookmarking there is only Microsoft's latest updates page.
MSSQL editions: Express, Developer, Standard and Enterprise
Editions are where SQL Server stops being like other databases. The engine is the same binary. What changes is a set of caps the licence enforces, and the caps moved in 2025, which means most of what's written about them online is wrong now.
Express is free and licensed for production use, customer-facing databases included. The maximum size of a single relational database was 10 GB through SQL Server 2022 and is 50 GB in SQL Server 2025. Five times the room, and for plenty of small databases that jump is the difference between running free and buying cores. The caps that didn't move are the ones that hurt: compute is limited to the lesser of one socket or four cores, and the buffer pool is 1,410 MB per instance. Hand an Express instance a 64 GB server and it will still hold 1.4 GB of data pages in memory.
Developer edition has every Enterprise feature switched on (on 2025 that's Enterprise Developer; Standard Developer mirrors Standard), costs nothing and is licensed for development and test only. Never production. The installer won't stop you either, so it ends up on production servers far more often than Microsoft would like.
Database size and buffer pool are the two numbers that decide most cases when you pick between SQL Server Express, Developer and Standard.
Standard in 2025 moved up to the lesser of 4 sockets or 32 cores with a 256 GB buffer pool, up from 24 cores and 128 GB in 2022, so a Standard licence stretches a good deal wider than it used to. Enterprise lifts the caps and the invoice reflects that. Production licensing for Standard and Enterprise is per-core and commercial, with a minimum of four core licences per physical processor and four per virtual machine when you licence individual VMs.
Where MSSQL runs: Windows, Linux and containers
SQL Server was a Windows-only product for most of its life and stopped being one in 2017. Nine years on, a good share of new deployments go straight to Linux. The targets are still not interchangeable. Windows carries every feature Microsoft ships, the Linux build gives you the engine with less around it, and containers run that same engine while adding a packaging problem you have to solve before anything starts.
Windows Server
The graphical installer is fine and I still use it on a machine I'm going to look after by hand. For anything repeatable, learn the command-line install, because it's the same syntax you'll paste into an image build later:
setup.exe /Q /ACTION=Install /FEATURES=SQLENGINE /INSTANCENAME=MSSQLSERVER ^
/SQLSYSADMINACCOUNTS="BUILTIN\Administrators" ^
/SECURITYMODE=SQL /SAPWD="<StrongPassword>" ^
/TCPENABLED=1 /IACCEPTSQLSERVERLICENSETERMS
/IACCEPTSQLSERVERLICENSETERMS is required and setup refuses to run without it. /SECURITYMODE=SQL is what turns on mixed mode, and it needs /SAPWD alongside it. Leave /SECURITYMODE out and you get Windows authentication only, which is the correct choice for a domain-joined server and the wrong one for a box that a Linux application connects to. /SQLSYSADMINACCOUNTS is mandatory on everything except Express.
The wizard path, the feature list and the parts worth changing are all in installing SQL Server on Windows Server. One warning from Microsoft's own install page that people ignore: installing over Remote Desktop from media on your local machine can fail, so put the ISO on the server or on a network share before you start.
Linux
Read the support matrix before you pick a distribution, because this is where most blog posts are simply wrong. SQL Server 2025 supports RHEL 9.x and 10.x plus Ubuntu 22.04 and 24.04, on XFS or ext4 file systems. SUSE Linux Enterprise Server was dropped in 2025. Debian has never been supported. SQL Server 2022 supports RHEL 8.x and 9.x, SLES 15 SP1 to SP4 and Ubuntu 20.04 and 22.04, with no 24.04 on the list at all.
The practical consequence is worth stating plainly: on Ubuntu 24.04 you install SQL Server 2025, not 2022. Every tutorial that tells you to add the 2022 repo on 24.04 is describing an unsupported combination that may install and will not be supported when it breaks.
Our step-by-step for installing SQL Server on Ubuntu 24.04 exists because the unattended setup variables are easy to get wrong and the password policy rejects half the passwords people try. The repo paths are in there too. The install itself is four commands once the repo is in place, and apt-key is gone, so anything still using it is out of date:
curl -fsSL https://packages.microsoft.com/keys/microsoft.asc | sudo gpg --dearmor -o /usr/share/keyrings/microsoft-prod.gpg
sudo apt-get update
sudo apt-get install -y mssql-server
sudo /opt/mssql/bin/mssql-conf setup
The tools are a separate package, mssql-tools18, and the binaries live in /opt/mssql-tools18/bin, which is not on your default PATH. Configuration on Linux happens through mssql-conf. Configuration Manager never made the crossing. The keys are written into /var/opt/mssql/mssql.conf and the ones you'll touch are network.tcpport, memory.memorylimitmb and sqlagent.enabled. Two defaults to change on day one: the memory limit is 80% of physical RAM, which is too greedy on a box running anything else, and SQL Server Agent is off.
While we're here. The Linux binary is sqlservr, with no 'e'. That spelling looks like a leftover of the 8.3 filename era on Windows. It has outlived every reason for it, and I still typo it about once a week.
Docker and containers
The container image is the fastest route to a working instance and the easiest one to get subtly wrong:
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
-p 1433:1433 --name sql1 --hostname sql1 \
-d \
mcr.microsoft.com/mssql/server:2025-latest
Use MSSQL_SA_PASSWORD. SA_PASSWORD is deprecated and still appears in thousands of copied compose files. Containers for SQL Server 2019 and later start as a non-root user by default, which is the right behaviour and the reason bind-mounted data directories need their ownership sorted out before the engine will start.
Most of the container failures I get asked about start in the Dockerfile, and the init-script patterns and volume permissions behind them are picked apart in running SQL Server in a Docker container. The shape of the problem is always the same. Someone wants their schema loaded at container start, so they set sqlcmd as the image's ENTRYPOINT or CMD. Now sqlservr never runs as PID 1, there's no engine for sqlcmd to talk to, and the container exits within seconds.
The engine has to be the main process. Init SQL runs from a wrapper that backgrounds sqlservr and polls for readiness, from a sidecar or from a Kubernetes init container.
Any of these run happily on a Linux VPS with NVMe storage, and the friction is in the setup and not the hardware. LumaDock's one-click MSSQL template deploys the engine on Ubuntu in a couple of minutes if you'd rather skip the repo dance, and it doesn't hand you a SQL Server licence. Bring a key for Standard or Enterprise, or keep the instance inside Express or Developer terms, which is where most of the setups described on this page live anyway.
SQL Server tools in 2026
The tooling story changed more in the last twelve months than it had in the previous five, and if you last set up a client environment in 2023 your muscle memory is out of date.
DBeaver and the VS Code extension both fall short somewhere, which SQL Server Management Studio setup and the alternatives is blunt about, alongside the install itself. SSMS is still the reference client and the current release is SSMS 22. It's Windows-only, 64-bit only, and it needs .NET Framework 4.8. The install route changed: SSMS now comes through the Visual Studio Installer, so you download a stub called vs_SSMS.exe and the updates arrive on the same channel as Visual Studio's. The standalone installer is gone. SSMS 22 also added initial Windows Arm64 support, which matters if you're on a Snapdragon laptop and have been running SSMS under emulation.
Azure Data Studio is dead. It was retired on 28 February 2026, with no more updates and no security fixes, so it's something to remove from your machines. Microsoft's retirement notice points everyone at Visual Studio Code with the MSSQL extension, which is the cross-platform answer now and on macOS or Linux the only first-party one. It's a decent editor with a connection manager and a query results grid. What it lacks is the estate management surface, so the maintenance plan designer and Activity Monitor stay behind on Windows. Plan for a Windows machine somewhere if you administer servers as well as query them.
The tool people forget entirely is SQL Server Configuration Manager, which ships with SQL Server and not with SSMS, and has no Start menu entry because it's an MMC snap-in. Run SQLServerManager17.msc for 2025 or SQLServerManager16.msc for 2022. That's where the TCP/IP protocol lives, and it answers a surprising share of "I can't connect" problems on Windows.
Machine Learning Services, the R and Python integration, is a blank spot for me. Eleven years of running these servers and it has stayed switched off on every one of them, so I have no view here worth your attention. If that's the part you came here for, this article is the wrong one.

