Skip to main content

Materialized Views

Materialized Views in ClickHouse

In ClickHouse, Materialized Views are the primary way to transform data. They are a persisted query result that is automatically updated when the underlying data changes.

You can use them to reshape, filter, or enrich data from one or more source Data Pools into a new Data Pool. For example, you could create a Materialized View that:

The transformed data in the destination Data Pool is automatically kept up-to-date as the underlying source data changes.

Illustration of data flowing from a source Data Pool, through a Materialized View, and into a destination Data Pool.

Illustration of data flowing from a source Data Pool, through a Materialized View, and into a destination Data Pool.

How do Materialized Views work?

Materialized Views in ClickHouse work by automatically executing a specified SQL query over new data inserted into a source Data Pool and writing the query results into a destination Data Pool.

When creating a Materialized View, you define a SELECT query that transforms or aggregates data from one or more source Data Pools. You also define a destination Data Pool where the resulting data will be written.

Diagram of (1) an insert to a source Data Pool, (2) the insert triggering a Materialized View, (3) the Materialized View executing its SQL query on the newly inserted data, and (4) the Materialized View’s query results being written to the destination Data Pool. Diagram of (1) an insert to a source Data Pool, (2) the insert triggering a Materialized View, (3) the Materialized View executing its SQL query on the newly inserted data, and (4) the Materialized View’s query results being written to the destination Data Pool.

Whenever new rows are inserted into the source Data Pools, Propel automatically triggers the Materialized View SQL query over just the new data and writes the results to the destination Data Pool. This allows incrementally updating the destination data Pool without re-computing the entire query from scratch.

Setting the Materialized View’s destination to a SummingMergeTree or AggregatingMergeTree Data Pool enables efficient incremental updates and storage of aggregations.

Materialized Views can be chained, with one Materialized View reading from the destination Data Pool of another, enabling multi-stage data transformation pipelines.

Creating a Materialized View

This section provides step-by-step instructions on creating a Materialized View in the Console, the API, and Terraform.


To start, go to the “Materialized Views” section of the Console, then click on “Create new Materialized View.”

A screen capture of the Materialized View section in the Propel Console

First, you need to enter the SQL query that will define the transformation. Once you have the query ready, Click “Continue.”

A screen capture of the "Define query" step of the create Materialized View flow in the Propel Console

For this example, we are going to create a new Data Pool, so select “New Data Pool” and give it a name.

A screen capture of the "Destination" step of the create Materialized View flow in the Propel Console

A screen capture of the "Destination name and description" step of the create Materialized View flow in the Propel Console

For this example, we are going to use the “Append-only data” settings. Answer the questions to generate the table settings. Select the “timestamp” column on the first question and click “Continue”.

A screen capture of the first "Destination table settings" step of the create Materialized View flow in the Propel Console

A screen capture of the second "Destination table settings" step of the create Materialized View flow in the Propel Console

Here, you will see your recommended table settings. Click “Continue”.

To learn more, see our How to select a table engine and sorting key guide.

A screen capture of the "Destination table settings review" step of the create Materialized View flow in the Propel Console

Next, decide whether you want to backfill the existing data in the source Data Pool to the destination Data Pool. In most cases, you’d want to backfill. Propel takes care of this process for you.

A screen capture of the "Backfill" step of the create Materialized View flow in the Propel Console

Lastly, give your Materialized View a name and description.

A screen capture of the "Name and description" step of the create Materialized View flow in the Propel Console

You’ll notice the new Data Pool is created with the new schema and data.

A screen capture of the Data Pool page in the Propel Console

Click on the “Preview Data” tab to see your transformed records.

A screen capture of the Data Pool "Preview Data" in the Propel Console


Materialized View examples

In this section, we will provide examples of common use cases solved with Materialized Views.

For all the examples, we’ll use a source Data Pool called events with two columns:

  • _propel_received_at (TIMESTAMP)
  • _propel_payload (JSON)

To replicate the examples, create a Webhook Data Pool with just the _propel_received_at and _propel_payload columns. Then click on the Data Pool, click on “Schema” tab and paste the event below to create sample records.

The JSON events in the _propel_payload column are of the form:

{
"customer_id": 5,
"order_id": 34,
"store_id": 4445,
"order_details": {
"taco_count": 7,
"price": 25.90,
"checkout_time": "2023-07-31T15:20:10Z"
},
"created_at": "2023-07-31T14:50:35Z"
}

For the API examples, you can copy and paste them to the API Playground.

Example 1: Flatten nested JSON into tabular form

The following Materialized View flattens the JSON into individual columns. In Propel, you can access nested JSON keys by using dot notation, as shown in the example below. We are also using the parseDateTimeBestEffort function to parse the timestamp from a string to ClickHouse timestamp.

SELECT
_propel_received_at,
"_propel_payload.customer_id" AS customer_id,
"_propel_payload.order_id" AS order_id,
"_propel_payload.store_id" AS store_id,
"_propel_payload.order_details.taco_count"::INTEGER AS taco_count,
"_propel_payload.order_details.price"::DOUBLE AS price,
parseDateTimeBestEffort("_propel_payload.order_details.checkout_time") AS checkout_time,
parseDateTimeBestEffort("_propel_payload.created_at") AS created_at
FROM events
Destination Data Pool
Table EngineMergeTree
Sorting Keycreated_at

Example 2: Combines data from multiple source tables through JOINs

Given an additional table stores with two columns,

  • store_id (STRING)
  • name (STRING)

The Materialized view below performs a JOIN to enrich the event with the store name.

Materialized Views trigger off the left-most table of the join which is considered the source Data Pool. The Materialized View will pull values from right-side tables in the join but will not trigger if those tables change.

SELECT
e._propel_received_at,
e."_propel_payload.customer_id" AS customer_id,
e."_propel_payload.order_id" AS order_id,
e."_propel_payload.store_id" AS store_id,
s.store_name AS store_name,
e."_propel_payload.order_details.taco_count"::INTEGER AS taco_count,
e."_propel_payload.order_details.price"::DOUBLE AS price,
e.parseDateTimeBestEffort(e."_propel_payload.order_details.checkout_time") AS checkout_time,
e.parseDateTimeBestEffort(e."_propel_payload.created_at") AS created_at
FROM events e
LEFT JOIN store s on e."_propel_payload.store_id" = s.store_id
Destination Data Pool
Table EngineMergeTree
Sorting Keycreated_at

Example 3: Calculates new derived columns from existing data

This Materialized View calculates the total price multiplying the taco_count times the price column.

SELECT
_propel_received_at,
"_propel_payload.customer_id" AS customer_id,
"_propel_payload.order_id" AS order_id,
"_propel_payload.store_id" AS store_id,
"_propel_payload.order_details.taco_count"::INTEGER AS taco_count,
"_propel_payload.order_details.price"::DOUBLE AS price,
parseDateTimeBestEffort("_propel_payload.order_details.checkout_time") AS checkout_time,
parseDateTimeBestEffort("_propel_payload.created_at") AS created_at,
round("_propel_payload.order_details.taco_count"::INTEGER * "_propel_payload.order_details.price"::DOUBLE, 2) AS total_price
FROM events
Destination Data Pool
Table EngineMergeTree
Sorting Keycreated_at

Example 4: Perform incremental aggregations

The Materialized View below incrementally aggregates the number of tacos sold and sales by customer_id and month. This Materialized View uses the SummingMergeTree table engine to incrementally aggregate rows as they are written. To learn more, read our guide on How to select a table engine and sorting key.

SELECT
toStartOfMonth(parseDateTimeBestEffort("_propel_payload.created_at")) AS month,
"_propel_payload.customer_id" AS customer_id,
SUM("_propel_payload.order_details.taco_count"::INTEGER) AS taco_count,
SUM(round("_propel_payload.order_details.taco_count"::INTEGER * "_propel_payload.order_details.price"::DOUBLE, 2)) AS total_sales
FROM events
GROUP BY
toStartOfMonth(parseDateTimeBestEffort("_propel_payload.created_at")),
customer_id
Destination Data Pool
Table EngineSummingMergeTree
Sorting Keymonth

Example 5: Sorts rows with a different sorting key

The Materialized View below creates a destination Data Pool with a different sorting key. It sorts the rows by the checkout_time column instead of the _propel_received_at column of the source Data Pool.

SELECT
*,
parseDateTimeBestEffort("_propel_payload.order_details.checkout_time") AS checkout_time
FROM events
Destination Data Pool
Table EngineMergeTree
Sorting Keycheckout_time

Example 6: Filters out unnecessary data based on conditions

The Materialized View below filters out rows older than 2024.

SELECT
*,
parseDateTimeBestEffort("_propel_payload.created_at") AS created_at
FROM events
WHERE parseDateTimeBestEffort("_propel_payload.created_at") > '2024-01-01'
Destination Data Pool
Table EngineMergeTree
Sorting Keycreated_at

Example 7: Deduplicating rows

The Materialized View below flattens and deduplicates events. It uses the ReplacingMergeTree table engine to duplicate events with the same sorting key. To learn more, read our guide on How to select a table engine and sorting key.

SELECT
_propel_received_at,
"_propel_payload.customer_id" AS customer_id,
"_propel_payload.order_id" AS order_id,
"_propel_payload.store_id" AS store_id,
"_propel_payload.order_details.taco_count"::INTEGER AS taco_count,
"_propel_payload.order_details.price"::DOUBLE AS price,
parseDateTimeBestEffort("_propel_payload.order_details.checkout_time") AS checkout_time,
parseDateTimeBestEffort("_propel_payload.created_at") AS created_at
FROM events
Destination Data Pool
Table EngineReplacingMergeTree
Sorting Keycreated_at, order_ids

Serverless ClickHouse guides

Frequently asked questions

What is the difference between materialized views and views?

In ClickHouse, a view is a virtual table based on the result set of a SELECT statement. It is used to simplify complex queries by breaking them up into manageable parts. A view always shows up-to-date data—the query is run every time the view is referenced in a query.

On the other hand, a Materialized View is a persisted version of a SELECT query's result set, which is automatically updated when the data underlying the query changes.

Do Materialized Views transform data in real-time or on a schedule?

Materialized Views in ClickHouse transform data in real-time. Whenever new data is inserted into the source Data Pool, the Materialized View is automatically triggered to transform the new data and write the results to the destination Data Pool.

How much do Materialized Views cost?

Materialized Views do not have a cost per se, but they incur data write costs just like any other Data Pool. Similarly, the destination Data Pools consume storage just like any other Data Pool.

What happens if I delete a Materialized View?

If you delete a Materialized View in Propel, new data will stop being inserted into the destination Data Pool. The destination Data Pool associated with it will not be automatically deleted.

Can a Materialized View be modified?

In ClickHouse, Materialized Views cannot be directly modified. If you need to change the fields or the query, you would need to create a new Materialized View.

What happens if I update or delete data in the source Data Pool with the update or delete API?

Data deleted or updated with the Batch update or delete API will not trigger the Materialized View and will not be propagated to the destination Data Pool.

Further reading


🤔Still have questions?
Post them to our Reddit discussion, and we’ll do our best to answer them.