1. Home
2. Storage
3. Tables & Aliases
4. Data Types

Data Types

• Base Types
• Data Type Conversions
  • STRING
  • INTEGER
  • NUMERIC
  • FLOAT
  • BOOLEAN
  • DATE
  • TIMESTAMP
• Native Data Types
  • How to Create a Typed Table
    • Manually via an API
    • Output mapping of a component
  • How to Define Data Types
    • Using actual data types of the storage backend
    • Using Keboola-provided base types
  • Changing Types of Existing Typed Columns
  • Incremental Loading
  • Handling NULLs
  • Pros and Cons

Some components, especially extractors (data sources), store metadata about the table columns. For example, when a DB extractor loads a table from a source database, it also records the physical column types from that table. These are stored with each table column and can be used later when working with the table. For instance, transformation COPY mapping allows you to set data types for the tables inside the transformations. Also, some writers (data destinations), e.g., the Snowflake writer, use the table metadata to pre-fill the table columns configuration for you.

Even if a data type is available for a column, storage always internally creates all table columns as text, not null, and nullable values are converted to empty strings (except for Exasol, where everything is null). Remember this, especially in transformations, where the output is always cast to text. This behavior can sometimes be changed with the native data types feature. The non-text column type is used only during a component (transformation or writer) execution. The basic idea behind this is that a text type has the best interoperability, so this averts many issues (e.g., some date values stored in a MySQL database might not be accepted by a Snowflake database and vice-versa).

Base Types

Source data types are mapped to a destination using a base type. The current base types are STRING, INTEGER, NUMERIC, FLOAT, BOOLEAN, DATE, and TIMESTAMP. This means that, for example, a MySQL extractor may store the value BIGINT as a type of column; that type maps to the INTEGER base type. When the Snowflake writer consumes this value, it will read the base type INTEGER and choose a corresponding type for Snowflake, which happens to be also INTEGER. This ensures high interoperability between the components. Please take a look at the conversion table below.

View the extracted data types in the storage table detail:

You can also override the data type:

When you use the table (e.g., in the Snowflake writer), you’ll see the data type you have configured:

Note that the column type setting is, in all cases, only a metadata setting. It does not affect the actual stored data. The data is converted only when writing or copying (e.g., to a transformation or a writer). That means that you can extract an integer column, mark it as a timestamp in storage and write it as an integer into a target database (though you’ll be offered to write it as a timestamp).

You access both the source and base type metadata through the corresponding API.

Data Type Conversions

As described above, the source data type is converted to a base data type stored in metadata storage. The base type is then converted to the target data type. The following tables show mappings for each base type. The mapping causes possible information loss (e.g., assigning SMALLINT to INTEGER). To minimize this, we also keep track of the data type size and transfer that if possible. For example, a SMALLINT column would be stored as base type INTEGER with size 2. If the target database supports integer sizes, you will be offered to set the type in the target database as INTEGER(2).

STRING

Base type STRING represents any textual type; both CHARACTER VARYING (or VARCHAR) and TEXT types are included. Also, the string base type is used for any other unrecognized type on input. It means that the source type column is not an exhaustive list in the following table. It’s a list of suitable string types converted to a string. All other unknown types are converted to a string as well.

INTEGER

The INTEGER base type represents data types for whole numbers.

NUMERIC

The NUMERIC base type represents fixed-point fractional numbers (real, numeric or decimal data types).

FLOAT

The FLOAT base type represents floating-point fractional numbers (float or double data types).

BOOLEAN

The BOOLEAN base type represents a true or false value.

DATE

The DATE base type represents a date value without a time portion.

TIMESTAMP

The TIMESTAMP base type represents a date value with a time portion.

Native Data Types

Specific behavior depends on the backend of your project. We’ll be using the Snowflake backend as an example.

As mentioned above, Keboola stores data in Storage as text (VARCHAR NOT NULL) by default. With native types, data is stored in columns with an actual data type (DATETIME, BOOLEAN, DOUBLE, etc.) based on Keboola metadata.

Tables with native data types are labeled in the user interface with a badge:

How to Create a Typed Table

Manually via an API

A table with a type definition is created using the tables-definition endpoint, and data is loaded into it. Data types used in this endpoint have to correspond with the storage backend which your project uses. Alternatively, you can use base types.

Output mapping of a component

A component may provide information about column data types in its data manifest. Database extractors and transformations matching the storage backend (e.g., Snowflake SQL transformation on the Snowflake storage backend) will create storage tables with the same types. The database extractors and transformations that do NOT match the backend will create storage tables using base types.

For example, this is how you can create typed tables in a Snowflake SQL transformation that will be imported to storage as typed tables:

-- create a table with datatypes
CREATE OR REPLACE TABLE "typed_table" (
    "id" NUMBER,
    "name" VARCHAR(255),
    "created_at" TIMESTAMP_NTZ
);

-- insert some data
INSERT INTO "typed_table"
VALUES
    (1, '75', '2020-01-01 00:00:00');

-- create another table with datatypes based on an existing table
CREATE OR REPLACE TABLE "typed_table_2" AS
SELECT
    "id"::varchar AS "string_id",
    "name"::number AS "numeric_name",
    "created_at"::date AS "typed_date"
FROM
    "typed_table";

Note: The data type hinting is the components’ responsibility, so components must be updated by their respective authors to support this. The database extractors that are maintained by Keboola already provide data types. There is no list of components that support this feature. You may check the component’s documentation to see if it supports native data types.

How to Define Data Types

Using actual data types of the storage backend

For example, in the case of Snowflake, you can create a column of type TIMESTAMP_NTZ or DECIMAL(20,2). This allows you to specify all the data type details, for instance, including precision and scale. But it’s tied to the specific storage backend, and thus it’s not portable.

An example of such a column definition in a table-definition API endpoint call is as follows:

{
  "name": "id",
  "definition": {
    "type": "DECIMAL",
      "length": "20,2",
      "nullable": false,
      "default": "999"
  }
}

Using Keboola-provided base types

Specifying native types using base types is ideal for component-provided types as they are storage backend agnostic. However, they can be used for the table-definition API endpoint as well. The definition is as follows:

{
  "name": "id",
  "basetype": "NUMERIC"
}

Changing Types of Existing Typed Columns

You can’t change the type of column of a typed table once it has been created. There are multiple ways to work around this.

First, if the table is loaded using full load, you can drop the table and create a new table with the correct types and load the data there.

If the table is loaded incrementally, you must create a new column and copy the data from the old one.

• You have a column date of type VARCHAR in a typed table, and you want to change it to TIMESTAMP.
• You first add a new column date_timestamp of type TIMESTAMP to the table.
• Then you change all the jobs filling the table to fill the new and old columns.
• Then you run an ad-hoc transformation, which will copy data from date to date_timestamp in the existing rows.
• Then you can slowly change all the places where date is used to use date_timestamp instead.
• When you only use the new column, the old one can be removed.

In both cases, check all the other configurations using the table to avoid any schema mismatch. This is especially important for data destination components (writers), where a table exists in the destination.

Incremental Loading

When you load data incrementally, there is a difference between typed and non-typed tables. Typed tables only compare the columns of the table’s primary key, while non-typed tables compare the whole row, updating rows where any value changes. This is described in detail in our documentation on incremental loading.

Handling NULLs

Columns without native types are always VARCHAR NOT NULL. This means you don’t need to care about a specific NULL behavior. This changes with typed columns. In most databases, NULL does not equal NULL (NULL == NULL is not TRUE, but NULL). This breaks the incremental loading flow where columns are compared against each other.

For this reason, please make sure that your primary key columns are not nullable. This is most relevant in CTAS queries, where columns are nullable by default. To work around this, specify the columns as part of the CTAS expression. For example:

CREATE TABLE "ctas_table" (
    "id" NUMBER NOT NULL,
    "name" VARCHAR(255) NOT NULL,
    "created_at" TIMESTAMP_NTZ NOT NULL
) AS SELECT * FROM "typed_table";

Pros and Cons

• Pros
  • Loading to a workspace is significantly faster than loading to a table without native data types. You don’t need just to cast the data when loading to a workspace.
  • A table accessed in a workspace via the read-only input mapping already has typed columns.
  • Data types are strictly enforced, so you can be sure your number column will contain only numbers, for example.
• Cons
  • Changing a column type is complicated; see Changing Types of Typed Columns.
  • Keboola won’t do any type conversion when loading. Your data must match the column type in the table in Storage exactly.
  • Any load of data with incompatible types will fail.