Data types

Every column has a fixed width on disk, so every row of a table has the same size. That rule shapes the type list: each type has a decided encoding, and a type without one is refused rather than approximated.

Types

Type	Storage	Notes
int8, int16, int32, int64	1, 2, 4, 8 bytes	The primary key (first column) must be one of these.
uint64	8 bytes	Full unsigned range. A negative literal is refused.
bool	1 byte
varchar	One cell of 64 bytes by default	The default width comes from the server setting inline_cell_width.
varchar(N)	One cell of N bytes, 16 ≤ N ≤ 4096	N is a width, not a maximum length. See below.
char, char(N)	N bytes (char is char(1))	Padded with zero bytes. A longer value, or one containing a zero byte, is refused.
date	4 bytes, days since 1970-01-01	Literal: '2026-08-09'
timestamp	8 bytes, microseconds since 1970-01-01 UTC	Literal: '2026-08-09 12:00:00'
decimal(p, s), p ≤ 18	8 bytes	Precision and scale are both required.
decimal(p, s), 19 ≤ p ≤ 38	16 bytes	Shown as decimal128(p,s) by DESCRIBE.

Examples

CREATE TABLE fares (
  id          int64,
  code        char(6),
  route       varchar(48),
  price       decimal(10, 2),
  active      bool,
  valid_from  date
);

How the types differ from standard SQL

varchar(N) sets a width, not a limit

N is the number of bytes the column takes in every row. A value longer than N - 3 bytes is stored outside the row and reads back the same. The only length limit is 8,144 bytes, one overflow page. Choose N so that your common values fit inside the row.

decimal needs a precision and a scale

A bare decimal is refused. A default scale would be a silent decision about what a stored amount means.

kdbs> CREATE TABLE t2 (id int64, fare decimal)
                                      ^
ERR column 'fare' needs a precision and a scale - `decimal(p, s)` - at byte 32; there is no default scale, because one would be a silent decision about what a stored value means

char(N) pads with zero bytes

'ab' and 'ab ' are different values. Use varchar for text that can contain any byte.

No float

float is refused at CREATE TABLE. Its comparison and rounding rules do not fit an engine that keeps values exact. Use decimal(p, s).

Literals and comparisons

• A literal is converted to the column’s type when the statement is compiled, not row by row. An invalid literal fails the statement once, with its byte position:

  kdbs> SELECT * FROM passengers WHERE joined_on = '2026-02-30'
                                                   ^
  ERR column 'joined_on' literal at byte 43: day 30 in '2026-02-30' is out of range for that month (28 days)
  

• No type is converted implicitly. A literal in a comparison must be written in the column type’s own form: an integer for an integer column (n = 20, never n = '20' or n = 20.0), a quoted string for char and varchar (s = '5', never s = 5), 0 or 1 for bool. A date or timestamp takes a string or its epoch integer, and a decimal a string or an integer. Anything else is refused when the statement is compiled:

  kdbs> SELECT * FROM passengers WHERE name = 5
                                              ^
  ERR column 'name' literal at byte 38: expects a string literal, '...'
  

• Two columns compare only within one family: integers of any width and signedness (compared by value), decimals of the same width and scale, char with varchar, date with date, timestamp with timestamp. See SELECT.

• Decimals of different precision or scale are never compared or combined implicitly. Rescaling would drop digits or invent them; use CAST or ROUND in an UPDATE expression.

• Columns are NOT NULL unless declared NULL. See CREATE TABLE.

Limitations

• A column’s type cannot be changed or widened after creation, because the row size is fixed.
• Values wider than 8,144 bytes are refused with NOT_IMPLEMENTED.