Materialize

Materialize is a streaming database. You define a view in SQL and it maintains the answer incrementally as new data arrives, so a SELECT against it is a lookup rather than a recomputation. It speaks the PostgreSQL wire protocol, so AddisDB connects with its Postgres driver — on port 6875, which is Materialize’s default rather than 5432.

Who it is for

Materialize suits teams who keep rewriting the same aggregations in application code or a stream processor and would rather write them once in SQL. Typical sources are Kafka topics and Postgres change feeds; typical consumers are dashboards and APIs that need an answer that is already current.

It is not a general-purpose OLTP database. Its objects are sources, views, materialized views, indexes and sinks, and its real catalog is mz_catalog — the pg_catalog it exposes is a compatibility shim so that Postgres clients can connect at all.

Set up the region

1. In the Materialize console open your region and copy the host — it looks like abcdef.us-east-1.aws.materialize.cloud.
2. The port is 6875.
3. Your username is the email address you sign in with.
4. Generate an app password from the console. That is what you authenticate with, not your account password.
5. Note the database (materialize) and the cluster you want queries to run on.

# Materialize on its own port, TLS required
psql 'postgres://you@example.com:APP_PASSWORD@abcdef.us-east-1.aws.materialize.cloud:6875/materialize?sslmode=require'

Connect from AddisDB

1. New Connection → Materialize. Port prefills to 6875, database and username to materialize.
2. Enter the host, your sign-in email as the username, and the app password.
3. Set SSL mode to require — Materialize Cloud will not accept a plaintext connection.
4. Test, then Save.

What AddisDB gives you

Queries and the schema tree. Your sources, views and materialized views appear as tables with their columns; introspection runs leniently so the pg_catalog sections Materialize does not implement come back empty rather than failing the load.

This is the useful shape for Materialize work: keep a query open against a materialized view and re-run it to watch the answer move, and use the results grid and exports as you would anywhere.

The Postgres-specific tooling is switched off. There is no Live Monitor, because Materialize has no pg_stat_activity — its own introspection lives in mz_catalog, and mz_internal.mz_recent_activity_log is the query you want. The structured create and alter table buttons are hidden, because creating a source or a materialized view is not shaped like CREATE TABLE and generated stock DDL would be rejected. Database-user management and test clones are off as well.