Scala 3.9 LTS Is Here. Should Production Teams Upgrade Yet?

Scala 3.9 is now the latest Long-Term Support release of Scala 3, replacing Scala 3.3 as the recommended LTS version.

For teams running Scala in production, particularly those responsible for services that need to remain stable for years rather than months, that makes 3.9 an important release.

But a new LTS version does not necessarily mean changing scalaVersion and deploying it next week.

The more useful question is what an upgrade would mean for the whole system around your Scala code.

What does Scala 3.9 LTS actually mean?

Long-Term Support releases are intended to provide a more stable foundation for teams that value predictability over adopting every new language release.

Scala 3.9 will receive long-term maintenance, while Scala 3.3 does not suddenly become obsolete. The Scala team plans to continue actively maintaining the 3.3 LTS line for another year.

That gives production teams something valuable: time.

Rather than treating the release as an urgent migration, teams can assess what moving to 3.9 would involve and choose an appropriate point in their development roadmap.

It is rarely just a Scala upgrade

One of the more important changes for teams coming from Scala 3.3 is the Java version underneath it.

Scala 3.9 requires JDK 17 or newer.

For a modern service that may already be completely unremarkable. But long-running Scala systems can have much older assumptions hidden in build pipelines, Docker images, deployment environments and supporting tooling.

The compiler may be the easy part.

Before upgrading, I would want to understand the versions of Java, sbt and plugins being used, whether important libraries support the new Scala version, and whether CI and deployment environments are ready for the same change.

That is why language upgrades are better treated as small software-modernisation projects rather than isolated version changes.

What about library compatibility?

This is particularly important with a new Scala LTS.

A large part of the Scala ecosystem has been built around Scala 3.3, and libraries published using Scala 3.9 cannot automatically be consumed by applications that remain on Scala 3.3.

For application teams, the practical question is therefore not simply whether Scala 3.9 is ready. It is whether the combination of libraries and frameworks their application depends on is ready too.

That might include a web framework, database drivers, JSON libraries, HTTP clients, testing tools and organisation-specific libraries.

The answer will be different for every codebase.

How I would approach the upgrade

I would start by understanding the system before changing anything.

Check the current JDK and build tooling. Review the important dependencies and plugins. Look for anything that has not been maintained recently or has unclear support for newer Scala versions.

Then make the changes incrementally.

The Scala team itself recommends upgrading the surrounding tooling and platform in stages rather than changing everything simultaneously. Keeping the build green between those stages makes it considerably easier to understand where a problem has been introduced.

For a production service, I would also want the existing test suite to be in good shape before beginning.

Compiler upgrades can expose warnings, deprecated behaviour or assumptions that have gone unnoticed for years. A strong automated test suite gives the team much more confidence that the application still behaves as expected after those changes.

And once it has been deployed, normal production monitoring still matters. Passing a build and passing automated tests are important, but they are not the same as observing how a real service behaves under real traffic.

Don't rush

Keeping software reasonably current matters.

Allowing language versions, libraries and build tooling to fall years behind eventually makes every future change harder. Security fixes become more difficult to adopt, engineers spend more time dealing with obsolete tooling, and what could have been a sequence of manageable upgrades turns into a major migration.

But the opposite extreme is not particularly useful either.

Production engineering is not about running the newest version of everything. It is about maintaining software that is secure, supportable and straightforward to change.

For teams currently running Scala 3.3 LTS successfully, Scala 3.9 is a good reason to start evaluating the next upgrade. It is not a reason to rush one through.

The right time to move is when the surrounding ecosystem is ready, the team understands the migration, and there is enough confidence in the tests and deployment process to make the change safely.

Our view: A new LTS release is a useful point to review the health of a Scala service, not just its compiler version. Scala 3.9 gives production teams a new long-term destination, but the real value comes from using the upgrade to understand dependencies, modernise tooling and make sure the service remains easy to maintain for the next few years.