Microsoft has shipped the first public release candidate of SQL Server 2025, delivering two long-awaited changes for teams that mix Windows infrastructure with Linux development: official support for Ubuntu 24.04 in dev and test environments, and Transport Layer Security (TLS) 1.3 enabled by default. The preview, designated RC0, arrives as an Enterprise Evaluation Edition with a 180-day license, explicitly targeted at early validation rather than production rollouts. But the same day the bits appeared, a separate community thread resurfaced a practical headache: Docker containers running older SQL Server builds on Ubuntu 24.04 can crash on startup with a SIGABRT, underscoring why careful testing matters before any live migration.

Ubuntu 24.04 joins the supported OS list—for now, only in the lab

For database teams that standardize on Canonical’s Long-Term Support releases, Ubuntu 24.04 represents the next natural platform anchor. The RC0 image spins up with a single docker pull command from Microsoft Container Registry: mcr.microsoft.com/mssql/server:2025-RC0-ubuntu-24.04. A simple docker run command, as shown in Microsoft’s quickstart, allocates the instance and exposes port 14333 for local connectivity. Developers can immediately begin validating application compatibility, driver behavior, and performance profiles against the new kernel and glibc versions that Ubuntu 24.04 introduces.

Yet the preview is deliberately gated. Microsoft’s SQL Server engineering team reiterated that production workloads should stay on SQL Server 2022 running on a certified Linux distribution—Ubuntu 22.04 or RHEL 9—until the next general availability milestone and formal support certification arrive. The 180-day evaluation license also means that any instance left running will cease to function when the timer expires, so it cannot become a forgotten production dependency.

Test engineers should check kernel compatibility for container hosts, storage driver interaction, and whether backup files created on Ubuntu 22.04 restore cleanly onto the 24.04 test image. Performance baselines should compare IO throughput, memory pressure, and CPU scaling against current production deployments. Observability tooling—agent-based monitors, audit pipelines, and log forwarders—must also be confirmed to work with the newer host environment. A structured test matrix covering these items will let teams decide when it is safe to plan a staged migration, rather than discovering breaking changes in a crisis.

TLS 1.3 by default reshapes connection security

The more impactful architectural change in RC0 is the switch to TLS 1.3 as the default protocol. Coupled with Tabular Data Stream (TDS) 8.0, the new connection sequence encrypts the prelogin and authentication phases earlier in the handshake. The previous order—TCP handshake, TDS prelogin, TLS handshake, then authentication—left initial negotiation traffic visible to passive observers. Now the flow becomes TCP handshake, TLS handshake, TDS prelogin (encrypted), authentication (encrypted), and data exchange (encrypted), drastically reducing the window for protocol-level attacks.

TLS 1.3 eliminates obsolete cipher suites and offers a faster, one-round-trip handshake compared to the two round trips common in TLS 1.2. For high-churn workloads—think microservices connecting to the database hundreds of times per second—the latency savings are measurable. Compliance auditors will also appreciate that the new default aligns with standards like PCI DSS 4.0 and NIST SP 800-52r2, which increasingly mandate modern Transport Layer Security.

However, the strong-by-default posture demands that IT teams reassess their entire client ecosystem. Legacy ODBC, JDBC, or .NET drivers that cannot negotiate TLS 1.3 will fail to connect. Middleboxes that terminate or inspect TLS traffic may not yet speak TLS 1.3 or recognize TDS 8.0, triggering silent denials or fallback to weaker—or even no—encryption. Microsoft’s documentation now includes verification steps to confirm that a session has negotiated TLS 1.3, but organizations should budget time for driver upgrades, connection-string audits, and controlled rollback plans before switching production workloads.

The container warning that flew under the radar

While the RC0 image targets Ubuntu 24.04 deliberately, an earlier issue on the Docker Community Forums serves as a clutch-check for any team picking up this preview. In mid-2024, a user reported that the official mcr.microsoft.com/mssql/server:2019-CU25-ubuntu-20.04 image crashed inside a VirtualBox VM running Ubuntu 24.04. The error log showed a SIGABRT from the sqlservr process with the fatal Reason 0x00000001, followed by an abort. The same image ran without trouble on Debian 12 and Windows 10 hosts, pointing a finger at the interplay between the older SQL Server build and the newer host kernel or userspace.

The reporter’s colleague could reproduce the crash on a fresh Ubuntu 24.04 VM, while a matching VM with Ubuntu 20.04 worked fine. A later test on bare-metal Ubuntu 24.04 was planned but not documented in the thread. Although the incident involved SQL Server 2019—not the RC0—it demonstrates that kernel upgrades, security-hardened defaults in newer LTS releases, or misaligned library versions can break containerized database engines. Microsoft’s RC0 engineering build may have already addressed similar compatibility gaps, but the anecdote reinforces a basic rule: if your organization’s test bench resembles the described setup, run a battery of startup and stress tests before assuming the new image will hum along.

Container-first testing: pull, run, verify

Microsoft’s container-focused delivery makes it dead simple to spin up a test instance. The following command sequence, taken from the official quickstart, gives developers a disposable playground:

docker pull mcr.microsoft.com/mssql/server:2025-RC0-ubuntu-24.04
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<your_password>" \
  -e "MSSQL_AGENT_ENABLED=true" -p 14333:1433 \
  --name sql2025preview -d mcr.microsoft.com/mssql/server:2025-RC0-ubuntu-24.04

Windows-based data professionals can layer Docker Desktop atop Windows Subsystem for Linux 2 (WSL2) and achieve a Linux-native file system and kernel without leaving their familiar desktop. Microsoft’s demos showed SQL Server Management Studio connecting from Windows to the container instance running inside WSL2, then inspecting the ERRORLOG to confirm the build number and Linux kernel version. This friction-free loop lowers the barrier for Windows-first teams to explore Linux-hosted scenarios.

Beyond the headline features: AI vectors, encryption upgrades, and driver performance

SQL Server 2025 is shaping up to be a platform release that reaches beyond OS support and transport security. Earlier CTP announcements and reports from Neowin and the SQL Server blog highlighted several additional capabilities:

  • Native vector embeddings: The database engine can store and process vector data, enabling retrieval-augmented generation (RAG) pipelines and AI workloads that require high-throughput embedding search. This positions SQL Server as a single platform for both relational and similarity-based queries.
  • Driver performance gains: Microsoft claims significantly faster reads, writes, and bulk-copy operations in preview drivers. As always with synthetic benchmarks, teams should validate those numbers against their own complex schemas and stored procedure workloads.
  • OAEP‑256 encryption: A stronger key-encryption algorithm becomes available when the database compatibility level meets the new threshold, giving security-sensitive workloads an extra layer of protection for asymmetric keys.

These additions make the release attractive but also broaden the testing surface. Each new feature demands its own validation script: query vector indexes for correctness, measure driver throughput under latch contention, and confirm that OAEP‑256 does not break existing key rotation procedures.

Migration posture: test widely, move cautiously

A risk matrix for moving from SQL Server 2022 to the 2025 RC0—and later to GA—highlights several watchpoints:

  • Database compatibility levels: Behavioral changes in T‑SQL, plan regression, or new error-handling semantics could surprise applications developed against older versions.
  • High availability features: Availability Groups, Failover Cluster Instances, and managed backup tools from third parties often trail the core engine in validation. Do not assume they will work on day one of RC0.
  • Third‑party ecosystem: Backup compression appliances, monitoring agents, and security scanners must be confirmed to handle TLS 1.3, TDS 8.0, and the new container image base.
  • Rollback proof: A backup taken on the RC0 instance must restore and operate correctly on a SQL Server 2022 production instance; otherwise, rollback is theoretical.

The recommended approach is to maintain production on SQL Server 2022, stand up a parallel test farm running RC0 on Ubuntu 24.04, and run identical workload replays. Developer workstations can adopt WSL2 + Docker Desktop for quick iterations, feeding findings back into the central test pipeline. Metadata about which drivers, connection strings, and compatibility levels succeed or fail should be stored in a central knowledge base so that the eventual GA migration is as automatic as possible.

Community reality check: excitement, skepticism, and kernel roulette

The broader conversation around this RC0 reveals a healthy mix of enthusiasm and caution. On Reddit and database-focused forums, early testers report spinning up the container successfully and quickly noticing the faster handshake with .NET 8 clients. Others, mindful of the Ubuntu 24.04 crash report from mid-2024, are holding back until they can test on physical hardware rather than nested virtualization.

Microsoft’s own blog comments include questions about certification timelines and whether Always Encrypted with secure enclaves works on Linux. The engineering team’s response has been to steer users toward the dev/test disclaimer while acknowledging that production certifications are a top priority for the GA timeline. Meanwhile, the Docker forum thread remains unresolved, with no official root cause analysis published for the SIGABRT. Until that post-mortem appears—or until the community confirms the issue does not affect the RC0 build—skeptical operators would be wise to log startup and crash dumps diligently during any Ubuntu 24.04 trial.

Recommendations for IT teams and DBAs

  1. Scope RC0 for validation, not migration. Use it to validate driver compatibility, performance profiles, and operational runbooks, but keep production on SQL Server 2022.
  2. Audit TLS 1.3 readiness immediately. The majority of connection failures reported in previews trace back to outdated client libraries. Upgrade JDBC, ODBC, and .NET drivers to versions that explicitly support TLS 1.3 and TDS 8.0.
  3. Build a containerized test harness. Docker Compose files that bring up the RC0 image, a test client, and a monitoring sidecar can be shared across engineering teams, ensuring consistent validation.
  4. Monitor community channels. The Docker forum crash thread and Microsoft’s GitHub issue trackers will likely surface any kernel-level compatibility regressions before they hit your environment.
  5. Plan for rollback. Document the exact steps to restore a backup from SQL Server 2025 to 2022, and test them repeatedly.

Final take

SQL Server 2025 RC0 is a meaningful preview that modernizes the SQL Server on Linux story. Ubuntu 24.04 support puts the engine on the latest LTS path, and TLS 1.3 by default closes a long-standing gap in transport security. Container delivery makes the bits instantly testable, and the accompanying quickstarts lower the barrier for Windows-based DBAs who want to explore Linux deployments. At the same time, the preview’s evaluation license, unresolved community reports of container failures on Ubuntu 24.04, and the heavy dependency on driver updates remind everyone that RC0 is a test vehicle, not a destination. The smart play is to start validating now, feed findings back into the ecosystem, and wait for GA certification before rewriting production runbooks.