How to Connect to SQL Server from macOS and Linux in 2026

SQL Server was long synonymous with Windows, ODBC, and Management Studio. Since SQL Server 2017 and the engine's arrival on Linux, the situation has changed: the TDS protocol is public, several native implementations exist outside the Microsoft ecosystem, and it is now possible to connect to a SQL Server instance from macOS or Linux without installing a single Windows component.

This article surveys the options available in 2026, from the terminal to graphical clients, and explains how each one handles the authentication modes typical of a SQL Server environment: SQL auth, Windows Auth (NTLM or Kerberos), and Azure Active Directory.

The Authentication Modes to Know

Before choosing a client, you need to know how the SQL Server instance expects its credentials. Four modes are common. SQL Authentication is the simplest mode: a login and a password stored in the instance, exactly like a PostgreSQL user. It's the preferred mode when connecting from a non-Windows OS, because it doesn't depend on Active Directory.

Windows NTLM lets you use a domain account in the format DOMAIN\\user or user@DOMAIN. The client sends an NTLM challenge to the instance, which validates it with the domain controller. Most modern TDS implementations support NTLM cross-platform, provided the client machine can reach the DC.

Windows Integrated reuses the current Windows session through SSPI. Outside Windows, it's rather a matter of Kerberos: a ticket obtained through kinit can be used by some libraries to authenticate without a password. The setup is more demanding because it requires a correct Kerberos configuration (krb5.conf file, the server's SPN, DNS).

Azure Active Directory mainly concerns Azure SQL Database and Azure SQL Managed Instance. Authentication is done via an OAuth2 token (with or without MFA). Support varies from one client to another: Azure Data Studio integrates it natively, some JDBC drivers require the Microsoft extension, and purely open source TDS drivers often cover only the password flow.

sqlcmd via Docker, the Terminal Option

Microsoft publishes the sqlcmd tool in an official Docker image (mcr.microsoft.com/mssql-tools). It's the fastest way to connect from a macOS or Linux machine without installing a single native dependency.

A typical session fits in one command: docker run -it --rm mcr.microsoft.com/mssql-tools /opt/mssql-tools/bin/sqlcmd -S serveur,1433 -U sa -P motdepasse -d ma_base. The tool supports SQL auth and Windows Auth (via Kerberos if the image is configured for it). It doesn't handle interactive AAD, and its ergonomics remain minimalist: no persistent history, no autocompletion, raw tabular output. It's exactly the right tool for quick scripting or diagnostics, but not for exploring a schema.

Azure Data Studio, the Official Cross-Platform Client

Azure Data Studio is the cross-platform successor to SQL Server Management Studio. Built on Electron and based on the same architecture as VS Code, it runs natively on Windows, macOS, and Linux. On the authentication side, it covers the whole spectrum: SQL auth, Windows Integrated, Windows NTLM, and Azure AD with MFA. It can also connect to Azure SQL through the cloud identity signed into the OS.

Its strength is full support for SQL Server specifics: T-SQL, graphical execution plans, monitoring dashboards, SQL notebooks, PostgreSQL extensions. The downside is that it remains centered on the Microsoft ecosystem. For someone juggling between SQL Server, PostgreSQL, and MongoDB, it becomes one more client to open in parallel.

DBeaver and DataGrip, the JDBC Generalists

DBeaver and DataGrip connect to SQL Server via JDBC. Both bundle the Microsoft mssql-jdbc driver, which speaks TDS and supports SQL auth, NTLM, Kerberos, and AAD (with or without MFA depending on the driver version). The advantage of the JDBC approach is uniformity: it's the same tools that handle PostgreSQL, MySQL, Oracle, and SQL Server.

The drawback is the dependency on a JVM. DBeaver has bundled its own JRE for several versions now, but the memory footprint remains high and the cold start is noticeable. The mssql-jdbc driver evolves quickly on the AAD side; you often have to keep a recent version to benefit from the most modern authentication flows (device code, managed identity).

QoreDB, a Native Tiberius Driver Without a JVM

QoreDB embeds a SQL Server driver written in Rust and based on Tiberius, the reference TDS library of the Rust ecosystem, coupled with the asynchronous connection pool bb8. No JVM, no ODBC component, no Microsoft installer to deploy on the machine. The application binary contains everything needed to open a TDS connection on port 1433.

On the authentication side, the driver handles three modes through a dedicated enum (MssqlAuthMode): SqlAuth for the classic login/password, WindowsNtlm for domain accounts in the DOMAIN\\user format, and WindowsIntegrated for reusing the OS session through SSPI on Windows or a Kerberos ticket on Unix. Validation is done before the connection: if you try to configure WindowsNtlm from macOS or Linux without a correct domain format, the error is returned immediately with an explicit message rather than an opaque failure on the server side.

Encryption follows the instance's configuration. When the connection requires TLS, EncryptionLevel switches to Required and the negotiation happens before the credentials are sent. The server's certificates are verified through the system CAs, and it's possible to provide a custom certificate for instances with an internal PKI. This mechanism is the same as that of QoreDB's other SQL drivers, which avoids having to learn a specific configuration per engine.

In Practice, from macOS or Linux

For a directly accessible instance, SQL Auth remains the simplest path: a hostname, a port, a login, a password. All the clients mentioned work in this case, and the differences come down mainly to ergonomics and memory footprint.

For an instance behind an Active Directory domain, NTLM is generally the mode that works cross-platform with the least configuration. You just have to make sure the machine resolves the domain controller and that the account is in the expected format. Kerberos is conceptually cleaner but requires a complete setup (krb5.conf, SPN, reverse DNS).

For an Azure SQL instance with interactive AAD and MFA, Azure Data Studio remains the most direct path. Generalist clients can connect to it via the password or device code flow depending on the driver, but the experience is less smooth.

When the instance is behind a bastion, the SSH tunnel is often unavoidable. Most desktop clients support it, but with varying implementations: DBeaver and DataGrip rely on JSch, QoreDB uses a native OpenSSH implementation integrated into Tauri, and sqlcmd depends on the OS tunnel. The typical scenario is: ssh -L 1433:sqlserver-interne:1433 bastion, then a local connection on 127.0.0.1.

Conclusion

Connecting to SQL Server from macOS or Linux has become a mundane use case in 2026. sqlcmd via Docker covers the terminal need, Azure Data Studio remains the reference for those who live in the Microsoft ecosystem, and generalist clients like DBeaver, DataGrip, or QoreDB let you keep a single interface for all your databases. The choice depends mainly on context: a machine that juggles between SQL Server and other engines benefits from using a multi-database client, ideally without a JVM to reduce the memory cost. This is the reasoning that guided the integration of Tiberius into QoreDB: a pure-Rust TDS driver, validated at compile time, that shares the same authentication, encryption, and tunneling model as the application's other drivers.