Managed¶

Most Vulcan models manage their own data, you run vulcan run, and Vulcan updates the tables. Managed models are different: the database engine handles data updates automatically in the background.

How it works: You define a query, and the engine monitors upstream tables. When source data changes, the engine automatically refreshes your managed table. No manual REFRESH commands needed, it just happens.

Use this for scenarios where you need always-fresh data without managing refresh schedules yourself. The engine handles the complexity of incremental updates, change detection, and refresh timing.

Best use case: Managed models are typically built on External Models rather than other Vulcan models. Since Vulcan already keeps its models up to date, the main benefit comes when you're reading from external tables that aren't tracked by Vulcan. The engine keeps your managed table in sync with those external sources automatically.

Difference from Materialized Views¶

What's the difference between a managed model and a materialized view?

Vulcan already supports materialized views, but they have limitations:

• Some engines only allow materialized views from a single base table

• Materialized views aren't automatically refreshed, you need to run REFRESH MATERIALIZED VIEW manually

• You're responsible for scheduling refreshes

Managed models are different:

• Automatic updates - The engine refreshes data when source tables change

• Smart refresh - The engine understands your query and can do incremental or full refreshes as needed

• No manual commands - Everything happens in the background

In some engines, there's no difference (they're the same thing). In others, managed models give you more automation and flexibility.

Lifecycle in Vulcan¶

Managed models follow the same lifecycle as other Vulcan models:

• Virtual environments create pointers to model snapshots

• Model changes create new snapshots

• Upstream changes trigger new snapshots

• You can deploy and rollback like any other model

• Snapshots get cleaned up when TTL expires

Cost consideration: Managed models usually cost more than regular tables. For example, Snowflake charges extra for Dynamic Tables. To save money, Vulcan uses regular tables for dev previews (in forward-only plans) and only creates managed tables when deploying to production.

Supported Engines¶

Currently, Vulcan supports managed models on:

To create a managed model, use the MANAGED model kind.

Snowflake¶

On Snowflake, managed models are implemented as Dynamic Tables. Dynamic Tables automatically refresh when their source data changes, which is exactly what managed models need.

Here's how you'd create one:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

MODEL (
  name db.events,
  kind MANAGED,
  physical_properties (
    warehouse = datalake,
    target_lag = '2 minutes',
    data_retention_time_in_days = 2
  )
);

SELECT
  event_date::DATE as event_date,
  event_payload::TEXT as payload
FROM raw_events

results in:

1
2
3
4
5
6
7
8

CREATE OR REPLACE DYNAMIC TABLE db.events
  WAREHOUSE = "datalake",
  TARGET_LAG = '2 minutes'
  DATA_RETENTION_TIME_IN_DAYS = 2
AS SELECT
  event_date::DATE as event_date,
  event_payload::TEXT as payload
FROM raw_events

Table Properties¶

Dynamic Tables have properties that control refresh frequency, initial data population, retention, and more. You can find the complete list in the Snowflake documentation.

In Vulcan, you set these properties using physical_properties in your model definition. Here are the key ones:

The following Dynamic Table properties can be set directly on the model: