Skip to main content

Event modeling

On this page, you will find the three event data model architectures that Mitzu supports. You can find more information in this blog post.

Single event tables​

This is the simplest of the three event data models. Each event you want to track should be stored in a separate table. Each table must contain the following columns:

  • User ID: The ID of the user that performed the event.
  • Event time: The time when the event occurred.
info

For single event tables, the name of the table describes the event that the user performed.

Wide multi event tables​

This event table model stores every event in a single table. The event properties for each event are stored in separate columns within the same table. This makes the table "wide", since the properties for each event don't always overlap and 100+ columns are often required.

The multi event table must contain the following columns:

  • User ID: The ID of the user that performed the event.
  • Event time: The time when the event occurred.
  • Event name: The name of the event that the user performed.
warning

Maintaining this table has some drawbacks. This table often has 100+ columns, which can be hard to maintain.

info

Since this table also contains all events for the product or service, it can hold a lot of data. This can make the table slow to query. We suggest partitioning this table by the event_name column and indexing it by the event_time column.

Short multi event tables​

This event table model stores every event in a single table. The event properties for each event are stored as MAP, JSON, or VARIANT types in the same table. This makes the table "short" because, with a single event_properties column, it is possible to store all of the event properties.

The multi event table must contain the following columns:

  • User ID: The ID of the user that performed the event.
  • Event time: The time when the event occurred.
  • Event name: The name of the event that the user performed.
warning

Maintaining this table has some drawbacks. The JSON, Map, or Variant types can cause performance issues.

info

Since this table also contains all events for the product or service, it can hold a lot of data. This can make the table slow to query. We suggest partitioning this table by the event_name column and indexing it by the event_time column.

If you are using Iceberg or Delta Lake tables, make sure your tables are optimized for querying.