Materialize Logo


Stable releases

Binary tarballs for all stable releases are provided below. Other installation options are available for the latest stable release on the Install page.

Version Release date Binary tarball links Supported
v0.5.2 18 November 2020 Linux / macOS
v0.5.1 6 November 2020 Linux / macOS
v0.5.0 21 October 2020 Linux / macOS
v0.4.3 17 September 2020 Linux / macOS
v0.4.2 3 September 2020 Linux / macOS
v0.4.1 19 August 2020 Linux / macOS
v0.4.0 27 July 2020 Linux / macOS
v0.3.1 3 July 2020 Linux / macOS
v0.3.0 1 June 2020 Linux / macOS
v0.2.2 11 May 2020 Linux / macOS
v0.2.1 30 April 2020 Linux / macOS
v0.2.0 11 April 2020 Linux / macOS
v0.1.3 17 March 2020 Linux / macOS
v0.1.2 04 March 2020 Linux / macOS
v0.1.1 22 February 2020 Linux / macOS
v0.1.0 13 February 2020 Linux / macOS

Binary tarballs require a recent version of their stated platform:

Unstable builds

Binary tarballs are built for every merge to the main branch on GitHub. These tarballs are not suitable for use in production. Run unstable builds at your own risk.

Version Binary tarball links
main Linux / macOS

The tarballs for other commits on main can be constructed by replacing latest in the links above with the full 40-character commit hash.


We offer support for the two most recent versions of Materialize. The currently supported versions are indicated in the table at the top of the page.

To engage with our community support team:

We do not investigate issues with unsupported versions of Materialize. If you are using an unsupported version, please check that the issue reproduces on a supported version before engaging with our support team.

Additional support options, including guaranteed SLAs, can be arranged upon request. Please reach out to our sales team at

Versioning policy


We issue a new release of Materialize every two weeks. Most releases are timed releases, which are cut on schedule, irrespective of what features and bugfixes have been merged. In rare cases, if severe regressions are discovered, we may skip a timed release.

Approximately every six weeks, we designate the regularly-scheduled timed release as a milestone release. These releases indicate the completion of a planned milestone, and may be delayed as necessary to allow for the completion of all scheduled tasks. Milestone releases are accompanied by a blog post that showcase the use cases enabled by the features added since the last milestone release.

Every year or two, we expect to designate a milestone release as a major release to mark a new era in Materialize’s development. The first major release of Materialize will be v1.0.0 and will bring improved stability, backward-compatibility, and support guarantees. We do not yet have a planned release date for v1.0.0.

Version numbering


We recommend that you upgrade to the latest version of Materialize as quickly as your schedule permits.

You should not assume that milestone releases will be more stable than timed releases or vice versa. We do not issue “bugfix-only” releases; any release, whether timed, milestone, or major, may include behavior changes and new features in addition to bugfixes.

Before upgrading, you should peruse the release notes for the new release to ensure your applications will not be affected adversely by any of the changes in the release.

Note that Materialize is not forwards compatible. Once you have upgraded to a newer version of Materialize, it may be impossible to roll back to an earlier version. Therefore, we recommend that you test upgrades in a staging cluster before upgrading your production cluster.

Backwards compatibility

Materialize maintains backward compatibility whenever possible. Applications that work with the current version of Materialize can expect to work with all future versions of Materialize with virtually no changes. Similarly, the data directory created by the current version of Materialize will be understood by all future versions of Materialize.

Very occasionally, a bugfix may require breaking backwards compatibility. These changes are approved only after weighing the severity of the bug against the number of users that will be affected by the backwards-incompatible change. Backwards-incompatible changes are always clearly marked as such in the release notes.

There are several aspects of the product that are not considered part of Materialize’s stable interface:

These unstable interfaces are not subject to the backwards-compatibility policy. If you choose to use these unstable interfaces, you do so at your own risk. Backwards-incompatible changes may be made to these unstable interfaces at any time and without mention in the release notes.