Releases

v26.5.1

Released to Materialize Self-Managed: 2025-12-23
Scheduled for release to Materialize Cloud: 2026-01-08

v26.5.1 enhances our SQL Server source, improves performance, and strengthens Materialize Self-Managed reliability.

Improvements

• VARCHAR(MAX) and NVARCHAR(MAX) support for SQL Server: The Materialize SQL Server source now supports varchar(max) and nvarchar(max) data types.
• Faster authentication for connection poolers: We’ve added an index to the pg_authid system catalog. This should significantly improve the performance of default authentication queries made by connection poolers like pgbouncer.
• Faster Kafka sink startup: We’ve updated the default Kafka progress topic configuration to reduce the amount of progress data processed when creating new Kafka sinks.
• dbt strict mode: We’ve introduced strict_mode to dbt-materialize, our dbt adapter. strict_mode enforces production-ready isolation rules and improves cluster health monitoring. It does so by validating source idempotency, schema isolation, cluster isolation and index restrictions.
• SQL Server Always On HA failover support (Materialize Self-Managed only): Materialize Self-Managed now offers better support for handling failovers, without downtime, in SQL Server Always On sources. Contact our support team to enable this in your environment.
• Auto-repair accidental changes (Materialize Self-Managed only): Improvements to the controller logic allow Materialize to auto-repair changes such as deleting a StatefulSet. This means that your production setups should be more robust in the face of accidental changes.
• Track deployment status after upgrades (Materialize Self-Managed only): The Materialize custom resource now displays both active and desired environmentd versions. This makes it easier to track deployment status after upgrades.

Bug fixes

• Added additional checks to string functions (replace, translate, etc.) to help prevent out-of-memory errors from inflationary string operations.
• Fixed an issue which could cause panics during connection drops; this means improved stability when clients disconnect.
• Fixed an issue where disabling console or balancers would fail if they were already running.
• Fixed an issue where balancerd failed to upgrade and remained stuck on its pre-upgrade version.

v26.4.0

Released to Materialize Self-Managed: 2025-12-17
Released to Materialize Cloud: 2025-12-18

v26.4.0 introduces several performance improvements and bugfixes.

Improvements

• Over 2x higher connections per second (CPS): We’ve optimized how Materialize handles inbound connection requests. In our tests, we’ve observed 2x - 4x improvements to the rate at which new client connections can be established. This is especially beneficial when spinning up new environments, warming up connection pools, or scaling client instances.
• Up to 3x faster hydration times for large PostgreSQL tables: We’ve reduced the overhead incurred by communication between multiple workers on a large cluster. We’ve observed up to 3x throughput improvement when ingesting 1 TB PostgreSQL tables on large clusters.
• More efficient source ingestion batching: Sources now batch writes more effectively. This can result in improved freshness and lower resource utilization, especially when a source is doing a large number of writes.
• CloudSQL HA failover support (Materialize Self-Managed only): Materialize Self-Managed now offers better support for handling failovers in CloudSQL HA sources, without downtime. Contact our support team to enable this in your environment.

Bug Fixes

• Fixed timestamp determination logic to handle empty read holds correctly.
• Fixed lazy creation of temporary schemas to prevent schema-related errors.
• Reduced SCRAM iterations in scalability framework and fixed fallback image configuration.

v26.3.0

Released Cloud: 2025-12-12
Released Self-Managed: 2025-12-12

Improvements

• For Self-Managed: added version upgrade window validation, to prevent skipping required intermediate versions during upgrades.
• Improved activity log throttling to apply across all statement executions, not just initial prepared statement execution, providing more consistent logging behavior.

Bug Fixes

• Fixed validation for replica sizes to prevent configurations with zero scale or workers, which previously caused division-by-zero errors and panics.
• Fixed frontend SELECT sequencing to gracefully handle collections that are dropped during real-time recent timestamp determination.

v26.2.0

Released Cloud: 2025-12-05
Released Self-Managed: 2025-12-09

This release focuses primarily on bug fixes.

Bug fixes

• Catalog updates: Fixed a bug where catalog item version updates were incorrectly ignored when the create_sql didn’t change, which could cause version updates to not be applied properly.

• Console division by zero: Fixed a division by zero error in the console, specifically when viewing mz_console_cluster_utilization_overview.

• ALTER SINK improvements: Fixed ALTER SINK ... SET FROM to prevent panics in certain situations.

• Improved rollout handling: Fixed an issue where rollouts could leave a pod at their previous configuration.

• Dependency drop handling: Fixed panics that could occur when dependencies are dropped during a SELECT or COPY TO. These operations now gracefully return a ConcurrentDependencyDrop error.

v26.1.0

Released Self-Managed: 2025-11-26

v26.1.0 introduces EXPLAIN ANALYZE CLUSTER, console bugfixes, and improvements for SQL Server support, including the ability to create a SQL Server Source via the Console.

EXPLAIN ANALYZE CLUSTER

The EXPLAIN ANALYZE statement helps analyze how objects, namely indexes or materialized views, are running. We’ve introduced a variation of this statement, EXPLAIN ANALYZE CLUSTER, which presents a summary of every object running on your current cluster.

You can use this statement to understand the CPU time spent and memory consumed per object on a given cluster. You can also reveal whether an object has skewed operators, where work isn’t evenly distributed among workers.

For example, to get a report on memory, you can run EXPLAIN ANALYZE CLUSTER MEMORY, and you’ll receive an output similar to the table below:

To understand worker skew, you can run EXPLAIN ANALYZE CLUSTER CPU WITH SKEW, and you’ll receive an output similar the table below:

Improved SQL Server support

Materialize v26.1.0 includes improved support for SQLServer, including the ability to create a SQLServer Source via the console.

Upgrade notes for v26.1.0

• To upgrade to v26.1 or future versions, you must first upgrade to v26.0

Self-Managed v26.0.0

Released: 2025-11-18

Swap support

Starting in v26.0.0, Self-Managed Materialize enables swap by default. Swap allows for infrequently accessed data to be moved from memory to disk. Enabling swap reduces the memory required to operate Materialize and improves cost efficiency.

To facilitate upgrades from v25.2, Self-Managed Materialize added new labels to the node selectors for clusterd pods:

• To upgrade using Materialize-provided Terraforms, upgrade your Terraform version to v0.6.1:

  • AWS Terraform v0.6.1 Upgrade Notes.
  • GCP Terraform v0.6.1 Upgrade Notes.
  • Azure Terraform v0.6.1 Upgrade Notes.

• To upgrade if not using a Materialize-provided Terraforms, you must prepare your nodes by adding the required labels. For detailed instructions, see Prepare for swap and upgrade to v26.0.

SASL/SCRAM-SHA-256 support

Starting in v26.0.0, Self-Managed Materialize supports SASL/SCRAM-SHA-256 authentication for PostgreSQL wire protocol connections. For more information, see Authentication.

When SASL authentication is enabled:

• PostgreSQL connections (e.g., psql, client libraries, connection poolers) use SCRAM-SHA-256 authentication
• HTTP/Web Console connections use standard password authentication

This hybrid approach provides maximum security for SQL connections while maintaining compatibility with web-based tools.

License Key

Starting in v26.0.0, Self-Managed Materialize requires a license key.

For new deployments, you configure your license key in the Kubernetes Secret resource during the installation process. For details, see the installation guides. For existing deployments, you can configure your license key via:

kubectl -n materialize-environment patch secret materialize-backend -p '{"stringData":{"license_key":"<your license key goes here>"}}' --type=merge

PostgreSQL: Source versioning

For PostgreSQL sources, starting in v26.0.0, Materialize introduces new syntax for CREATE SOURCE and CREATE TABLE to allow better handle DDL changes to the upstream PostgreSQL tables.

To create a source from an external PostgreSQL:

CREATE SOURCE [IF NOT EXISTS] <source_name>
[IN CLUSTER <cluster_name>]
FROM POSTGRES CONNECTION <connection_name> (PUBLICATION '<publication_name>')
;

To create a read-only table from a source connected (via native connector) to an external PostgreSQL:

CREATE TABLE [IF NOT EXISTS] <table_name> FROM SOURCE <source_name> (REFERENCE <upstream_table>)
[WITH (
    TEXT COLUMNS (<column_name> [, ...])
  | EXCLUDE COLUMNS (<column_name> [, ...])
  [, ...]
)]
;

Creating the tables from sources starts the snapshotting process. Snapshotting syncs the currently available data into Materialize. Because the initial snapshot is persisted in the storage layer atomically (i.e., at the same ingestion timestamp), you are not able to query the table until snapshotting is complete.

For more information, see:

• Guide: Handling upstream schema changes with zero downtime
• CREATE SOURCE
• CREATE TABLE

Deprecation

The inPlaceRollout setting has been deprecated and will be ignored. Instead, use the new setting rolloutStrategy to specify either:

• WaitUntilReady (Default)
• ImmediatelyPromoteCausingDowntime

For more information, see rolloutStrategy.

Terraform helpers

Corresponding to the v26.0.0 release, the following versions of the sample Terraform modules have been released:

Upgrade notes for v26.0.0

• Upgrading to v26.0.0 is a major version upgrade. To upgrade to v26.0 from v25.2.X or v25.1, you must first upgrade to v25.2.16 and then upgrade to v26.0.0.

• For upgrades, the inPlaceRollout setting has been deprecated and will be ignored. Instead, use the new setting rolloutStrategy to specify either:

  • WaitUntilReady (Default)
  • ImmediatelyPromoteCausingDowntime

  For more information, see rolloutStrategy.

• New requirements were introduced for license keys. To upgrade, you will first need to add a license key to the backendSecret used in the spec for your Materialize resource.

  See License key for details on getting your license key.

• Swap is now enabled by default. Swap reduces the memory required to operate Materialize and improves cost efficiency. Upgrading to v26.0 requires some preparation to ensure Kubernetes nodes are labeled and configured correctly. As such:

  • If you are using the Materialize-provided Terraforms, upgrade to version v0.6.1 of the Terraform.

  • If you are not using a Materialize-provided Terraform, refer to Prepare for swap and upgrade to v26.0.

See also Version specific upgrade notes.

See also

• Release Schedule