Skip to main content

Supported Types

Data types

The data types are derived from the types defined in the JSON schema specification.

The type and format properties in schemas are used to determine the data type of the field. The type property indicates the type of the field. The format property provides additional information about the underlying type. Fields will always have a type property, but some may also have a format property. The JSON schema specification already defines a set of common formats. We support these formats and define others as well.

For optimal performance and efficient data layout, we also impose some restrictions on what data types can be used for primary key fields.

The full list of supported type and format are listed below.

tip

Note that the client libraries that we provide use language-idiomatic types for the types and formats below. For example, while a 64-bit integer is represented as type integer in JSON requests and responses, but our Java client library uses the Java long type.

TypeFormatDescriptionSupported for Key FieldsSupported for autoGenerate
integerA 64-bit integral number. Optionally, format can be specified as int64.YesYes
integerint32A 32-bit integral number.YesYes
numberA double-precision 64-bit IEEE 754 floating point. Optionally, format can be specified as double.NoNo
numberfloatA single-precision 32-bit IEEE 754 floating point.NoNo
stringAn arbitrary string. It may contain Unicode characters.YesYes
stringbyteBinary data in an undifferentiated byte stream.YesYes
stringuuidUniversally unique identifiers (UUIDs). UUIDs are 16-byte numbers used to uniquely identify records.YesYes
stringdate-timeAn RFC3339 timestamp in UTC time. This in the format of yyyy-MM-ddTHH:mm:ss.SSSZ. The milliseconds portion (".SSS") is optional.YesYes
booleanA boolean value, either "true" or "false".NoNo
arrayAn array of values. The items property indicates the schema for the array values.NoNo
objectA container type that stores other fields. The properties key defines the schema for the object, but is optional. To store semi-structured data where schema may not be known you can omit properties.NoNo

int64

Representing 64-bit integral numbers.

{
"age": {
"type": "integer"
}
}

int32

Representing 32-bit integral numbers.

{
"age": {
"type": "integer",
"format": "int32"
}
}

double

Representing double-precision 64-bit IEEE 754 floating point values.

{
"balance": {
"type": "number"
}
}

float

Representing single-precision 32-bit IEEE 754 floating point values.

{
"balance": {
"type": "number",
"format": "float"
}
}

byte

Representing binary data in an undifferentiated byte stream.

{
"data": {
"type": "string",
"format": "byte"
}
}

string

Representing strings of text that may contain Unicode characters.

{
"name": {
"type": "string"
}
}

uuid

Representing universally unique identifiers (UUIDs). UUIDs are 16-byte numbers used to uniquely identify records.

{
"cart_id": {
"type": "string",
"format": "uuid"
}
}

date-time

Representing an RFC3339 timestamp in UTC time.

{
"order_date": {
"type": "string",
"format": "date-time"
}
}

boolean

Representing a boolean value, either "true" or "false".

{
"is_active": {
"type": "boolean"
}
}

array

Representing an array of values. The items property indicates the data type for the array values.

{
"languages": {
"type": "array",
"items": {
"type": "string"
}
}
}

object

Representing a container type that stores other fields. The properties key defines the schema for the object.

{
"address": {
"type": "object",
"properties": {
"street": {
"type": "string"
},
"city": {
"type": "string"
},
"state": {
"type": "string"
},
"zip": {
"type": "integer"
}
}
}
}

Tigris also supports storing semi-structured data for objects where the schema is not known. This is done by omitting the properties key which is optional for the object data type.

{
"event_data": {
"type": "object"
}
}

Nested data

This section demonstrates schema with nested data.

Array

Data of type array requires the items keyword to be expressed as JSON key. This defines the type of items that will be in the array.

The example below extends the schema for the user collection by adding the field languages

{
"languages": {
"type": "array",
"items": {
"type": "string"
}
}
}

Object

Data of type object requires the properties keyword to be expressed as JSON key. This is similar to the top-level properties key and specifies the fields that make up the object.

The example below extends the schema for the user collection by adding the field address

{
"address": {
"type": "object",
"properties": {
"street": {
"type": "string"
},
"city": {
"type": "string"
},
"state": {
"type": "string"
},
"zip": {
"type": "integer"
}
}
}
}

Below is what the complete schema looks like with the addition of the two new fields languages and address

{
"title": "users",
"properties": {
"id": {
"type": "integer"
},
"name": {
"type": "string",
"maxLength": 100
},
"balance": {
"type": "number"
},
"languages": {
"type": "array",
"items": {
"type": "string"
}
},
"address": {
"type": "object",
"properties": {
"street": {
"type": "string"
},
"city": {
"type": "string"
},
"state": {
"type": "string"
},
"zip": {
"type": "integer"
}
}
}
},
"primary_key": ["id"]
}

Null Values

null is an allowed value that can be used with any of the fields in the schema except for the ones that are part of the primary key definition. If a field is set to the null value, then the document stored in the database will have that field set to the null value. If you are looking for the behavior where you would like fields without any values to not be stored as part of the document, then simply skip setting them to any value.