Squidex 7.18 adds early support for MySQL, Postgres and SQL Server as storage backends, and slims down the official container by moving ImageMagick and Kafka behind build flags. This update walks through what changed in Q1 2025, what you need to do if you relied on the removed libraries, and which search and identity bugs were fixed.
Two releases went out in the first quarter of 2025: 7.17.0 and 7.18.0. The larger of the two is 7.18.0, which introduces relational database support and changes what is bundled in the official container image. If you self-host Squidex, read the container section carefully before you upgrade.
Squidex 7.18.0 adds support for MySQL, Postgres and SQL Server as storage backends. Until now, MongoDB was the only option, which meant that a Squidex deployment had to bring a document database along even in environments where a relational database was already the standard, managed and monitored.
This is an early version. A large number of tests have been implemented to verify that the SQL backends behave correctly, but the feature has not had the years of production exposure that the MongoDB backend has. The practical advice that follows from that:
If your organization has a database team that is comfortable with Postgres or SQL Server and would rather not add MongoDB to the list of systems it operates, this release gives you something concrete to test.
Two native or heavyweight dependencies were removed from the official container image in 7.18.0 to reduce its size: ImageMagick and Kafka.
ImageMagick is the native library that Squidex used to analyze and resize images. It is no longer required, because the .NET library ImageSharp handles all the image formats properly. If you have a workload where you specifically want ImageMagick back, you have two options: use the dedicated image resize server, or build your own container or binaries with the library included.
With Docker:
docker build . --build-arg SQUIDEX__BUILD__ARGS="-p:DefineConstants=INCLUDE_MAGICK"
With the .NET CLI:
dotnet build -p:DefineConstants=INCLUDE_MAGICK
Kafka support was removed from the container for the same reason. If you use the Kafka rule action, you need to build Squidex yourself with the Kafka constant defined.
With Docker:
docker build . --build-arg SQUIDEX__BUILD__ARGS="-p:DefineConstants=INCLUDE_KAFKA"
With the .NET CLI:
dotnet build -p:DefineConstants=INCLUDE_KAFKA
These are the changes most likely to affect an existing deployment, so check whether you have a Kafka rule configured before you pull the new image. Image handling should continue to work without any action on your side, since ImageSharp covers the formats that ImageMagick was used for.
Squidex can delegate full-text search to an external engine instead of the built-in implementation. Two fixes in 7.18.0 address that integration: one for Azure Search and one for Elastic Search.
If you configured either engine and saw content that was indexed but not returned by queries, or queries that failed outright, upgrade and re-check your search behaviour. It is worth running a small set of known queries against a schema you understand well, so you can tell the difference between an indexing problem and a query problem.
The identity area got attention in both releases of the quarter.
In 7.17.0, a setting was added to map errors that come from identity servers to user-friendly messages. External identity providers tend to return error codes and phrasing that only make sense to whoever configured the provider. With this setting you can translate those into text that an editor logging into your Squidex instance can act on, instead of an opaque provider error.
In 7.18.0, logout was fixed so that the user is redirected to the specified URL after a successful logout. If you embed Squidex in a wider single sign-on setup and expect users to land on a portal page after signing out, this is the fix that makes that work.
The remaining changes are smaller but worth knowing about. In the Management UI, the autocompletion field is clickable again, after a regression made it respond only to keyboard input. On the event side, events can now be replayed when the end of the MongoDB commit log has been reached, which matters if you rebuild projections or replay an event stream as part of an operational task. And the build itself was reworked to run steps in parallel, which shortens the turnaround time if you compile Squidex from source yourself.
The full details for both releases are in the changelog, and the deployment options, including the build arguments shown above, are documented at docs.squidex.io. If you want to try the SQL backends, start with a throwaway environment and report what you find on GitHub, since early feedback is what moves that feature forward.