SlicingDice Documentation

SlicingDice - The All-in-One Solution Documentation

Welcome to the SlicingDice documentation. You'll find comprehensive guides and documentation to help you start working with SlicingDice as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started    Guides

2. SlicingDice Key Concepts

Below we describe few but crucial terms and concepts used by SlicingDice. Understanding these concepts will simplify and accelerate your comprehension of how and why to use SlicingDice. You should know:

The last section of this page contains a side-by-side comparison between SlicingDice's concepts/paradigms to other standard databases.

Overview of the SlicingDice's Key Concepts

Watch this quick video below to learn more about SlicingDice's Key Concepts.


SlicingDice columns are exactly like regular columns in a database or on a spreadsheet. Every column on SlicingDice is always associated with a dimension, that is explained in another section below.

SlicingDice supports two main types of columns, attribute and event columns. The following is a summary of the differences between the columns:

Attribute Column

This column type is used to store supported data types not associated to a date/time. An attribute describes the facts, details or characteristics of an entity. For example, you can use them to store: the name, age, and gender of users; the region or type of your server or IOT device, and so on.

Check some examples of how to create columns and how to insert data into attribute columns.

Event Column

This column type is used to store supported data types that are associated to a date/time. For instance, you can track a click on a button in your Click event column by storing the value Add to Cart and the date/time of the event {% convert_date 'YYYY-MM-DDT10:35:23Z' '-1d' %}.

Check some examples of how to create columns and how to insert data into event columns. Further, you can also check an in-depth review of the differences between attribute and event columns.

One of the main advantages of SlicingDice's columns is that you can add or remove new columns at any time, without any performance penalty.
You don't need to think or plan in advance how to model your database schema, as this can be executed and easily changed on the fly.

Column usage in practice

Below is an example of a SlicingDice database with three columns, which two of them are attribute columns (Name and Age) and one is an event column (Clicks), in which all the data stored is associated to one entity (UUID-01).





Add to Cart - {% convert_date 'YYYY-MM-DDT12:54:12Z' '-10d' %}
Pay Now - {% convert_date 'YYYY-MM-DDT10:22:10Z' '-5d' %}
Support - {% convert_date 'YYYY-MM-DDT17:05:25Z' '-2d' %}

As you can notice above, the columns Name and Age are storing information that doesn't need to be associated to a date/time, because it's a fact, not an event/transaction. On the other hand, the column Clicks is precisely storing clicks on buttons, so the data must have an association to a date/time, in order for the user to know when the event happened.

Entity / Entities

An entity is basically to "whom" the data that will be inserted and stored on a database.

An entity is like a primary key. SlicingDice uses the entities to associate any data inserted on the database, that could be a user email address, a device identification number, a server's hostname, etc.

To make things clear, take a look at the data table below. As you can see, there are three columns, Name, Age and Clicks, and its values are associated to the corresponding User IDs, UUID-01, UUID-02 and UUID-03. These User IDs are the Entity ID for whom the data was inserted.

User ID




Add to Cart - {% convert_date 'YYYY-MM-DDT12:54:12Z' '-10d' %}
Pay Now - {% convert_date 'YYYY-MM-DDT10:22:10Z' '-5d' %}
Support - {% convert_date 'YYYY-MM-DDT17:05:25Z' '-2d' %}




Add to Cart - {% convert_date 'YYYY-MM-DDT12:54:12Z' '-10d' %}
Support - {% convert_date 'YYYY-MM-DDT17:05:25Z' '-2d' %}




Add to Cart - {% convert_date 'YYYY-MM-DDT12:54:12Z' '-10d' %}
Pay Now - {% convert_date 'YYYY-MM-DDT10:22:10Z' '-5d' %}

Every entity must have a unique identifier, a string that uniquely identifies it. For instance, your users' email address, MAC Address or your server hostname are perfect as unique entity IDs.

When you create a database or a dimension, SlicingDice automatically creates a Unique ID column type called Entity ID (with API name entity-id) for that dimension. This column will be transparently used by SlicingDice to store the value of all the entities you insert on the dimension. It's not possible to delete this column.

It's important to note that this column does not count for price calculations.


A dimension is a way to group columns for a database. Each database may contain multiple dimensions and each dimension can contain multiple columns.

In a relational database, you normally create tables and build relations between them.
But SlicingDice doesn't have the concept of a table, because it doesn't need to.

As SlicingDice supports storing both types of data, attributes (non-time-series) and events (time-series) in the same dimension (that can be seen as a single table), without affecting the query performance or database storage size, there is no need to split and normalize the data into multiple tables, as it's commonly done in other databases.

The purpose of a dimension is simply to group all columns created, similarly how a table work in a database. We just don't call it "table", because that could give the impression that we expect you to model your schema in a relational way, which is unnecessary using SlicingDice.

Learn more about how to create dimensions.

SlicingDice vs other Databases

Considering all the concepts presented above, we've prepared a quick video and the comparison table below to help you understand how these conceptual differences affect your work and the way you use SlicingDice.

Standard Databases Paradigm
SlicingDice Paradigm

Tables and Relational Model

Considering that you have multiple datasets, containing both types of data, attributes (non-time-series) and events (time-series), normally you would need to create two (or more) tables on the database: one table to store the events (time-series) and another to store the attributes (non-time-series). Because of that, when you need to make a query that requires columns present on both tables, you must make a JOIN between them, which usually hampers performance.

SlicingDice doesn't have the concept of tables and the equivalent is what we call Dimension, that is basically a way to group many columns together.
The difference is that you can store both types of data, attributes (non-time-series) and events (time-series) in the same dimension, without affecting the query performance or database storage size.
Because of this, you never forced to use JOINs on your queries, as all your columns can be stored on the same dimension (like storing all columns on a same table).

Schema Definition

In order to save storage space and have a good query performance, normally you would need to think about your database schema and data model in advance and, once it's done, you can't make dramatic changes on it without affecting your database stability and performance.

SlicingDice allows you to add and delete dimension and columns as needed, changing your database schema at any time without any interruption or degradation on the service and performance.

Data Sharding / Partitioning

Considering that you have a dataset with millions (or billions) of rows, in order to have insertion and query performance and system scalability, you would have to manually shard/partition your data, or at least define some shard/partition key that the database will use to split and distribute your data over servers/nodes.

SlicingDice doesn't have the concept of partition and you don't need to worry about this kind of thing.
Each dimension has its own Entity and the entity's values will be automatically used by our platform to evenly distribute your data across our servers.

Time-series Sharding / Partitioning

Considering that you have a big time-series dataset, normally you would have to manually shard/partition your data by date/time in order to have system scalability and allow your queries to run faster.

As explained above, you don't need to worry about sharding or partitioning your data, doesn't matter if the type of data is attributes or events (time-series).
SlicingDice will intelligently and automatically store your time-series data in the most effective way, and ensure 10 second or less query times.

Index Creation

In order to improve query performance, you would have to constantly tune your database and add indexes to the most used columns.

SlicingDice doesn't give you options to tune your database, because we believe this is our job.
There is no need to add indexes to your columns, because all of them are already indexed by default. This is one of the reasons why SlicingDice is very fast for BI/Cube and OLAP use cases, because no matter the combination of columns on your queries, it will always use the columns’ indexes.

To summarize the differences presented above, we can define that:

SlicingDice provides databases that can handle time-series (events) and non-time-series (attributes) type of data, discarding the need of JOINs on the queries by being able to use a single dimension to store all the data, in which the datasets doesn't have to be manually sharded/partitioned by the user and where all the columns automatically have an index, making all the queries run very fast.

2. SlicingDice Key Concepts

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.