Warehouse Schemas

When sending your events to a data warehouse via RudderStack, you don't need to define a schema for the event data before sending it from your source. Instead, RudderStack automatically does that for you by following a predefined warehouse schema.

This guide details the structure of this warehouse schema and the columns created in different tables based on different events.

Schema

RudderStack uses the source name (written in snake case, for example, source_name) to create a schema in your data warehouse (also called a dataset, in the case of Google BigQuery).

The following is a list of tables created for each RudderStack source that is connected to the warehouse:

Table NameDescription
<test_source_name>.tracksEvery track call sent to RudderStack is stored in this table.

It does not include the custom properties sent under the properties key in the event but has some standard properties (listed in theStandard Properties section below) such as received_at, anonymous_id, context_device_info, etc.
<test_source_name>.<track_event_name>All the standard properties, along with the custom properties for atrack call, are stored in this table.

The table name is the event name specified in the track call. For example: Added to Cart
<test_source_name>.identifies

Every identify call sent to RudderStack is stored in this table.

It also includes all the properties passed as traits in the identify call.

<test_source_name>.usersRudderStack stores all the unique users in this table.

Only the latest properties used to identify a user are stored in it, including the latest anonymousId.
<test_source_name>.pagesEvery page call sent to RudderStack is stored in this table.

This includes all the properties sent in the page event.
<test_source_name>.screensEvery screen call sent to RudderStack is stored in this table.

This includes all the properties sent in the screen event.
<test_source_name>.groupsEvery group call sent to RudderStack is stored in this table.

This includes all the properties sent in the group event.
<test_source_name>.aliasesEvery alias call sent to RudderStack is stored in this table.

This includes all the properties sent in the alias event.

All the properties in the event are stored as top-level columns in the corresponding table. Nested properties will be prefixed with the parent key. For example, an event with properties as shown: { product: { name: iPhone, version: 11 }} will results in the columns product_name and product_version.

Standard RudderStack Properties

RudderStack sets the following standard properties on all the above mentioned tables:

Column NameDescription
anonymous_idThe anonymous ID of the user.
context_<prop>Context properties set in the event.
id

The unique message ID of the event, except for the userstable.

The field will be the user ID in case of users table.

sent_atTimestamp set by the RudderStack SDK when the event was sent from the client to RudderStack.
received_atTimestamp registered by RudderStack when the event was ingested (received).
original_timestampTimestamp registered by the RudderStack SDK when the event call was invoked (event was emitted in the SDK).
timestampThis is calculated by RudderStack to account for theclient clock skew. The formula used is: timestamp =receivedAt - (sentAt -originalTimestamp).
event_textName of the event mapped from the event key in the payload for the track events.
eventThe name of the event table for the track calls.

RudderStack reserves the above-mentioned standard properties. In the case of any conflict, RudderStack automatically discards the properties set by the user.

Clock Skew Considerations

RudderStack considers the time at its end to be absolute and assumes any difference on the client-side. Thus, the client clock skew is relative.

sentAt > original_timestamp is always true. However, timestamp can be more or less than the original_timestamp. Refer to the examples below for more details.

Here's an example of original_timestamp < received_at(The client-side time is less than the server-side time):

original_timestampsent_atreceived_at

timestamp= received_at -

(sent_at - original_timestamp)

2020-04-26 07:00:43.4002020-04-26 07:00:45.1242020-04-26 07:00:45.5582020-04-26 07:00:44.834

In this case, timestamp will be greater than original_timestamp.

Here's an example of original_timestamp > received_at (The client-side time is more than the server-side time):

original_timestampsent_atreceived_at

timestamp= received_at -

(sent_at - original_timestamp)

2020-04-26 07:00:45.5582020-04-26 07:00:46.1242020-04-26 07:00:43.4002020-04-26 07:00:43.9650

In this case, timestamp will be less than original_timestamp.

Table Schemas

This section covers the major table schemas for different types of events.

Track

RudderStack creates a record in both the tracks and <event_name> tables for every track call.

A sample Add to Cart event made from the JavaScript SDK is as shown below:

// track call using JavaScript SDK
rudderanalytics.track(
"Add to Cart",
{
price: 5,
currency: "USD",
product_id: "P12345",
product_name: "N95 Mask",
},
{
context: {
ip: "0.0.0.0",
},
anonymousId: "59b703e3-467a-4a1d-9fe6-da27ed319619",
}
)

The corresponding schemas created for the tracks and add_to_cart tables is as shown:

Table: tracks

ColumnTypeValueDescription
idStringe.g.4d5a7681-e596-40ea-a81c-bf69f9b297f1Unique messageId generated by RudderStack.
anonymous_idStringe.g.59b703e3-467a-4a1d-9fe6-da27ed319619The anonymous ID of the user.
received_atTimestampe.g.2020-04-26 07:00:45.558Timestamp registered by RudderStack when the event was ingested (received).
sent_atTimestampe.g.2020-04-26 07:00:45.124Timestamp set by the SDK when the event was sent from the client to RudderStack.
original_timestampTimestampe.g.2020-04-26 07:00:43.400Timestamp registered by the SDK when the event call was invoked (event was emitted in the SDK).
timestampTimestampe.g.2020-04-26 07:00:44.834Calculated by RudderStack to account for the client clock skew. The formula used is: timestamp = receivedAt - (sentAt - originalTimestamp).
context_ipString0.0.0.0-
context_<prop>String, Inte.g.context_app_version: 1.2.3, context_screen_density: 2-
eventStringadd_to_cartThe name of the corresponding event table.
event_textStringAdd to CartThe name of the event.
uuid_tsTimestampe.g.2020-04-26 07:31:54:735Added by RudderStack for debugging purposes. Can be ignored for analytics.

Table: add_to_cart

ColumnTypeValueNote
idStringe.g. 4d5a7681-e596-40ea-a81c-bf69f9b297f1Unique messageIdgenerated by RudderStack
anonymous_idStringe.g. 59b703e3-467a-4a1d-9fe6-da27ed319619-
received_atTimestampe.g. 2020-04-26 07:00:45.558-
sent_atTimestampe.g. 2020-04-26 07:00:45.124-
original_timestampTimestampe.g.2020-04-26 07:00:43.400-
timestampTimestampe.g. 2020-04-26 07:00:44.834-
context_ipString0.0.0.0-
context_<prop>String, Inte.g. context_app_version: 1.2.3, context_screen_density: 2-
eventStringadd_to_cartThe name of the event table
event_textStringAdd to CartThe name of the event
priceInt5-
currencyStringUSD-
product_idStringP12345-
product_nameStringN95 Mask-
uuid_tsTimestampe.g. 2020-04-26 07:31:54:735Added by RudderStack for debugging purposes. Can be ignored for analytics purposes

The event table add_to_cart has all the columns as the tracks table. It also has the properties set by the user inside the key properties.

Identify

RudderStack creates a record in the identifies table and upserts the records in the users table for every identify call, based on the userId.

In case of Google BigQuery, you can use the views created over the tables to query for unique users in the dataset. Refer to the BigQuery documentation for more details.

A sample identify event made from the JavaScript SDK is as shown below:

rudderanalytics.identify(
"U-12345",
{
email: "john@rudderstack.com",
first_name: "John",
last_name: "Doe",
age: 35,
},
{
context: {
ip: "0.0.0.0",
},
anonymousId: "59b703e3-467a-4a1d-9fe6-da27ed319619",
}
)

The corresponding schemas created for the identifies and users tables is as shown:

Table: identifies

ColumnTypeValueNote
idStringe.g. 4d5a7681-e596-40ea-a81c-bf69f9b297f1Unique messageId generated by RudderStack.
user_idStringU-12345The userId in the identify call.
anonymous_idString59b703e3-467a-4a1d-9fe6-da27ed319619-
received_atTimestampe.g. 2020-04-26 07:00:45.558-
sent_atTimestampe.g. 2020-04-26 07:00:45.124-
original_timestampTimestampe.g. 2020-04-26 07:00:43.400-
timestampTimestampe.g. 2020-04-26 07:00:44.834-
context_ipString0.0.0.0-
context_<prop>String, Inte.g. context_app_version: 1.2.3, context_screen_density: 2-
emailStringjohn@rudderstack.com-
first_nameStringJohn-
last_nameStringDoe-
ageInt35-
uuid_tsTimestampe.g. 2020-04-26 07:31:54:735Added by RudderStack for debugging purposes. Can be ignored for analytics.

Table: users

ColumnTypeValueNote
idStringU-12345The unique user ID.
received_atTimestampe.g. 2020-04-26 07:00:45.558-
context_ipString0.0.0.0-
context_<prop>e.g. String, Inte.g. context_app_version: 1.2.3, context_screen_density: 2-
emailStringjohn@rudderstack.com-
first_nameStringJohn-
last_nameStringDoe-
ageInt35-
uuid_tsTimestampe.g. 2020-04-26 07:31:54:735Added by RudderStack for debugging purposes. Can be ignored for analytics purposes

The users table has the properties from the latest identify call made for an user. It only has the id column (same as user_id in identifies table) and does not have the anonymous_id column.

To get at a user’s anonymous_id, you can query the identifies table by grouping on the user_id column.

Page & Screen

RudderStack creates a record in the pages or screen table for every page/screen call.

A sample page event is as shown below:

rudderanalytics.page(
"Cart",
"Cart Viewed",
{
path: "/cart",
title: "Shopping Cart",
url: "https://rudderstack.com",
},
{
context: {
ip: "0.0.0.0",
},
anonymousId: "59b703e3-467a-4a1d-9fe6-da27ed319619",
}
)

The corresponding schema created for the pages table is as shown:

Table: pages/screens

ColumnTypeValueNote
idStringe.g. 4d5a7681-e596-40ea-a81c-bf69f9b297f1-
anonymous_idString59b703e3-467a-4a1d-9fe6-da27ed319619-
received_atTimestampe.g. 2020-04-26 07:00:45.558-
sent_atTimestampe.g. 2020-04-26 07:00:45.124-
original_timestampTimestampe.g. 2020-04-26 07:00:43.400-
timestampTimestampe.g. 2020-04-26 07:00:44.834-
context_ipString0.0.0.0-
context_<prop>e.g. String, Inte.g. context_app_version: 1.2.3, context_screen_density: 2-
nameStringCart ViewedThe page name.
categoryStringCartThe page category.
pathString/cart-
titleStringShopping Cart-
urlStringhttps://rudderstack.com``-
uuid_tsTimestampeg. 2020-04-26 07:31:54:735Added by RudderStack for debugging purposes. Can be ignored for analytics.

Group

RudderStack creates a record in the groups table for every group call.

A sample group call is as shown below:

rudderanalytics.group(
"DevOps",
{
email: "john@rudderstack.com",
first_name: "John",
last_name: "Doe",
age: 35,
},
{
context: {
ip: "0.0.0.0",
},
anonymousId: "59b703e3-467a-4a1d-9fe6-da27ed319619",
}
)

The corresponding schemas created for the groups table is as shown:

Table: groups

ColumnTypeValueNote
idStringe.g. 4d5a7681-e596-40ea-a81c-bf69f9b297f1The group ID associated with the current user.
anonymous_idString59b703e3-467a-4a1d-9fe6-da27ed319619-
group_idStringDevOps-
received_atTimestampe.g. 2020-04-26 07:00:45.558-
sent_atTimestampe.g. 2020-04-26 07:00:45.124-
original_timestampTimestampe.g. 2020-04-26 07:00:43.400-
timestampTimestampe.g. 2020-04-26 07:00:44.834-
context_ipString0.0.0.0-
context_<prop>e.g. String, Inte.g. context_app_version: 1.2.3, context_screen_density: 2-
uuid_tsTimestampe.g. 2020-04-26 07:31:54:735Added by RudderStack for debugging purposes. Can be ignored for analytics.

Accepted Timestamp Formats

RudderStack only recognizes a subset of the ISO 8601 timestamp formats as a timestamp. Listed below are the accepted timestamp formats:

  • 2019-09-26
  • 2009-05-19 14:39:22
  • 2019-09-26T06:30:12.984Z
  • 2020-02-11 04:56:55.175116
  • 2019-09-26T06:30:12.984+0530
  • 2019-09-26T06:30:12.984+05:30

RudderStack does not recognize any other timestamp format apart from the formats mentioned above.

Reserved Keywords

Note that there are some limitations when it comes to using the reserved words in a schema, table, or column names. If these words are used in the event names, traits or properties, RudderStack automatically prefixes a _ when creating tables or columns for them in your schema.

Also, note that integers are not allowed at the start of the schema or table name. Such schema, column, or table names will be prefixed with a _. For instance, 25dollarpurchase will be changed to _25dollarpurchase.

Find more details about the list of reserved keywords in the following warehouse-specific docs.

WarehouseReference
Amazon RedshiftLink
Google BigQueryLink
SnowflakeLink

How RudderStack Handles Data Type Mismatch

Once RudderStack recognizes and sets a data type for a table column, it will not accept any values for the column that cannot be cast to the specified data type.

The values which cannot be cast are set as NULL in the table and stored in the rudder_discards table.

The schema of the rudder_discards table is as shown below:

ColumnNote
row_id

Unique Identifier (ID) associated with each record in the table.

This corresponds to the unique messageId for all the tables except for users table, where it isuserId.

table_nameThe table name where the full record is inserted, liketracks, add_to_cart, identifies , etc.
column_nameThe column name corresponding to the property to be added.
column_valueThe column value which caused the data type mismatch and is discarded.

The row_id is the column which users can use to join with original table and update it as required. It is set to messageId for all tables except the users table, where it corresponds to userId.

Shown below is a sample event whose properties are discarded due to a mismatch in the data type of the previous events:

// intial track call using the RudderStack JavaScript SDK
rudderanalytics.track(
"Add to Cart",
{
price: 5, // originally a int value
currency: "USD",
product_id: "P12345",
product_name: "N95 Mask",
added_at: "2020-05-19 14:39:22", // originally a datetime value
},
{
context: {
ip: "0.0.0.0",
},
anonymousId: "59b703e3-467a-4a1d-9fe6-da27ed319619",
}
)
// subsequent track call using the RudderStack JavaScript SDK
rudderanalytics.track(
"Add to Cart",
{
price: "NA", // sent as a string in latest event
currency: "USD",
product_id: 789, // sent as int but can be casted into original string data type
product_name: "N95 Mask",
added_at: "05/25/2020", // sent as invalid datetime value
},
{
context: {
ip: "0.0.0.0",
},
anonymousId: "59b703e3-467a-4a1d-9fe6-da27ed319619",
}
)

The subsequent records created in the rudder_discards table for the discarded properties from the second event listed in the example above are as shown:

Row IDTable NameColumn NameColumn Value
a21620be-6502-44d6-941d-78209a386d58add_to_cartpriceNA
1e42b2b3-8b6a-49da-8502-83a8db334375add_to_cartadded_at05/25/2020

FAQs

Can I change the namespace (schema name) of my data warehouse in RudderStack?

Yes, you can. Although the default namespace will be the source name with some modifications to it, RudderStack also provides an option in the dashboard to explicitly set the namespace of the dataset in the warehouse.

Refer to the warehouse-specific destination settings for configuring the namespace in the RudderStack dashboard.

Contact Us

For any queries on any of the sections covered in this guide, feel free to contact us or start a conversation on our Slack channel.