CipherStash Documentation

Data types

CipherStash QX does not place restrictions on the data that can be stored within it. After all, as an encrypted data store, CipherStash QX has no idea what it is that is being stored. However, in order for querying to work, the indexes need to have correct and consistent data stored in them. Towards that end, we carefully define what are valid and invalid values, and the ordering semantics for those values.

In order for a value to be indexed, it must be one of the following data types. Data that is not one of these data types cannot be indexed by any of the available indexes in CipherStash QX.


A 64-bit floating-point number, which corresponds to the IEEE754-2008 binary64 double-precision type. All values that can be represented by a double-precision floating-point number are acceptable, with the exception of NaN (”not-a-number”). Negative zero is treated as equal to zero. Ordering is the expected numeric order, with negative infinity sorting less than all finite values, and positive infinity sorting greater than all finite values.

A float64 can be used in these indexes:


A 64-bit unsigned integer, capable of representing any integer in the range 0 to 264 - 1, inclusive. Ordering is the numeric ordering you’d likely expect from such a data type.

A uint64 can be used in these indexes:


A sequence of valid UTF-8 codepoints of any length.

Strings currently have a very limited sort ordering defined. See the documentation for the range index type for details.

A string can be used in these indexes:


A value that can be either true or false. All true values are equal to all other true values, and all false values are equal to all over false values. All false values sort as “less than” all true values.

A boolean can be used in these indexes:


A timestamp with millisecond precision. The internal representation is the number of milliseconds before or after 1970-01-01 00:00:00 UTC, stored in a 64-bit signed integer. This means that dates from about 292 million years ago, to about 292 million years in the future, can be stored. If you’re working on dinosaur fossils, you may have problems, but otherwise you should be fine.

Conversion from other means of expressing time to the internal representation will attempt to account for leap seconds to the extent possible, however for times far in the future this is not always entirely possible, due to the unpredictable nature of leap seconds.

A date can be used in these indexes: