SQL Reference

Data types

NameDescriptionLength constraints
INTEGERSigned 64-bit integer value. Usually referred to as BIGINT in other databases.-
BOOLEANA boolean value, either TRUE or FALSE-
VARCHARUTF8-encoded textMaximum number of bytes in the UTF-8 encoded representation of the string
BLOBsequence of bytesMaximum number of bytes in the sequence

Size constraints

Size constraint is specified with a [MAX_SIZE] suffix on the type, e.g. BLOB[16] represents a sequence of up to 16 bytes.

NULL values

NULL values in immudb are not unique - two NULL values are considered equal on comparisons.

Creating tables

Common examples of CREATE TABLE statements are presented below.

  1. CREATE TABLE IF NOT EXISTS customers (
  2. id INTEGER,
  3. customer_name VARCHAR[60],
  4. email VARCHAR[150],
  5. address VARCHAR,
  6. city VARCHAR,
  7. ip VARCHAR[40],
  8. country VARCHAR[15],
  9. age INTEGER,
  10. active BOOLEAN,
  11. PRIMARY KEY (id)
  12. );
  13. CREATE TABLE IF NOT EXISTS products (
  14. id INTEGER,
  15. product VARCHAR NOT NULL,
  16. price VARCHAR NOT NULL,
  17. PRIMARY KEY (id)
  18. );
  19. CREATE TABLE IF NOT EXISTS orders (
  20. id INTEGER AUTO_INCREMENT,
  21. customerid INTEGER,
  22. productid INTEGER,
  23. PRIMARY KEY id
  24. );
  25. CREATE TABLE customer_review(
  26. customerid INTEGER,
  27. productid INTEGER,
  28. review VARCHAR,
  29. PRIMARY KEY (customerid, productid)
  30. );

IF NOT EXISTS

With this clause the CREATE TABLE statement will not fail if a table with same name already exists.

Note: If the table already exists, it is not compared against the provided table definition neither it is updated to match it.

NOT NULL

Columns marked as not null can not have a null value assigned.

PRIMARY KEY

Every table in immudb must have a primary key. Primary key can use at least 1 and up to 8 columns.

Columns used in a primary key can not have NULL values assigned, even if those columns are not explicitly marked as NOT NULL.

Primary key creates an implicit unique index on all contained columns.

AUTO_INCREMENT

A single-column PRIMARY KEY can be marked as AUTO_INCREMENT. immudb will automatically set a unique value of this column for new rows.

When inserting data into a table with an INSERT statement, the value for such primary key must be omitted. When updating data in such table with UPSERT statement, the value for such primary key is obligatory and the UPSERT statement can only update existing rows.

The type of an AUTO_INCREMENT column must be INTEGER. Internally immudb will assign sequentially increasing values for new rows ensuring this value is unique within a single table.

Foreign keys

Explicit support for relations to foreign tables is not currently supported in immudb. It is possible however to create ordinary columns containing foreign key values that can be used in JOIN statements. Application logic is responsible for ensuring data consistency and foreign key constraints.

  1. SELECT * FROM orders
  2. INNER JOIN customers ON customers.id = orders.customerid
  3. INNER JOIN products ON products.id = orders.productid;

Indexes

immudb indexes can be used for a quick search of rows with columns having specific values.

Certain operations such as ordering values with ORDER BY clause require columns to be indexed.

  1. CREATE INDEX ON customers(customer_name);
  2. CREATE INDEX ON customers(country, ip);
  3. CREATE INDEX IF NOT EXISTS ON customers(active);
  4. CREATE UNIQUE INDEX ON customers(email);

Index can only be added to an empty table.

Index do not have explicit name and is referenced by the ordered list of indexed columns.

Column value constraints

Columns of BLOB or VARCHAR type must have a size limit set on them. The maximum allowed value size for one indexed column is 256 bytes.

Values for indexed columns can not be NULL even if the column is not explicitly marked as NOT NULL.

Unique indexes

Index can be marked as unique with extra UNIQUE keyword. Unique index will prevent insertion of new data into the table that would violate uniqueness of indexed columns within the table.

Multi-column indexes

Index can be set on up to 8 columns. The order of columns is important when doing range scans, iterating over such index will first sort by the value of the first column, then by the second and so on.

Note: Large indexes will increase the storage requirement and will reduce the performance of data insertion. Iterating using small indexes will also be faster than with the large ones.

IF NOT EXISTS

With this clause the CREATE INDEX statement will not fail if an index with same type and list of columns already exists. This includes a use case where the table is not empty which can be used to simplify database schema initialization.

Note: If the index already exists, it is not compared against the provided index definition neither it is updated to match it.

Inserting or updating data

INSERT

immudb supports standard INSERT sql statement. It can be used to add one or multiple values within the same transaction.

  1. INSERT INTO customers (
  2. id, customer_name, email, address,
  3. city, ip, country, age, active
  4. )
  5. VALUES (
  6. 1,
  7. 'Isidro Behnen',
  8. 'ibehnen0@mail.ru',
  9. 'ibehnen0@chronoengine.com',
  10. 'Arvika',
  11. '127.0.0.15',
  12. 'SE',
  13. 24,
  14. true
  15. );
  16. INSERT INTO products (id, product, price)
  17. VALUES
  18. ( 1, 'Juice - V8, Tomato', '$4.04' ),
  19. ( 2, 'Milk', '$3.24' );
  20. INSERT INTO orders (customerid, productid)
  21. VALUES (1, 1), (1, 2);
  22. INSERT INTO customer_review (customerid, productid, review)
  23. VALUES
  24. (1, 1, 'Nice Juice!');

UPSERT

UPSERT is an operation with a syntax similar to INSERT, the difference between those two is that UPSERT either creates a new or replaces an existing row. A new row is created if an entry with the same primary key does not yet exist in the table, otherwise the current row is replaced with the new one.

Currently UPSERT can only be performed on tables without secondary indexes (other than the one used for the primary key). This constraint will be removed in the future.

If a table contains an AUTO_INCREMENT primary key, the value for that key must be provided and the UPSERT operation will only update the existing row.

  1. UPSERT INTO products (id, product, price)
  2. VALUES
  3. ( 2, 'Milk', '$3.17' ),
  4. ( 3, 'Grapes - Red', '$5.03' );
  5. UPSERT INTO orders (id, customerid, productid)
  6. VALUES (1, 1, 3);

Querying

Selecting all columns

All columns from all joined tables can be queried with SELECT * statement.

  1. SELECT *
  2. FROM products;

Selecting specific columns

  1. SELECT id, customer_name, ip
  2. FROM customers;

Filtering entries

  1. SELECT id, customer_name, email
  2. FROM customers
  3. WHERE country = 'SE' AND city = 'Arvika';

Ordering by column value

  1. SELECT id, customer_name
  2. FROM customers
  3. ORDER BY customer_name ASC;

Currently only one column can be used in the ORDER BY clause.

The order may be either ascending (ASC suffix, default) or descending (DESC suffix).

Ordering rows by a value of a column requires a matching index on that column.

INNER JOIN

immudb supports standard SQL INNER JOIN syntax. The INNER join type is optional.

  1. SELECT *
  2. FROM orders
  3. INNER JOIN customers ON orders.customerid = customers.id;
  4. SELECT *
  5. FROM orders
  6. JOIN customers ON orders.customerid = customers.id
  7. WHERE orders.productid = 2;
  8. SELECT * FROM orders
  9. JOIN customers ON customers.id = orders.customerid
  10. JOIN products ON products.id = orders.productid;

LIKE operator

immudb supports the LIKE operator. Unlike in other SQL engines though, the pattern use a regexp syntax supported by the regexp library in the go language SQL Reference - 图1 (opens new window).

A NOT prefix negates the value of the LIKE operator.

  1. SELECT product
  2. FROM products
  3. WHERE product LIKE '(J.*ce|Red)';
  4. SELECT product
  5. FROM products
  6. WHERE product NOT LIKE '(J.*ce|Red)';
  7. SELECT id, product
  8. FROM products
  9. WHERE (id > 0 AND NOT products.id >= 10)
  10. AND (products.product LIKE 'J');

IN operator

immudb has a basic supports for the IN operator.

A NOT prefix negates the value of the IN operator.

Note: Currently the list for the IN operator can not be calculated using a sub-query.

  1. SELECT product
  2. FROM products
  3. WHERE product IN ('Milk', 'Grapes - Red');
  4. SELECT product
  5. FROM products
  6. WHERE product NOT IN ('Milk', 'Grapes - Red');
  7. SELECT id, product
  8. FROM products
  9. WHERE (id > 0 AND NOT products.id >= 10)
  10. AND (product IN ('Milk', 'Grapes - Red'));

Column and table aliasing

  1. SELECT c.id, c.customer_name AS name, active
  2. FROM customers AS c
  3. WHERE c.id <= 3 AND c.active = true;
  4. SELECT c.id, c.customer_name AS name, active
  5. FROM customers c
  6. WHERE c.id <= 3 AND c.active = true;

Table name aliasing is necessary when using more than one join with the same table.

Aggregations

Available aggregation functions:

  • COUNT
  • SUM
  • MAX
  • MIN
  • AVG
  1. SELECT
  2. COUNT() AS c,
  3. SUM(age),
  4. MIN(age),
  5. MAX(age),
  6. AVG(age)
  7. FROM customers;

Grouping results with GROUP BY

Results can be grouped by a value of a single column. That column must also be used in a matching ORDER BY clause.

  1. SELECT COUNT() as customer_count, country
  2. FROM customers
  3. GROUP BY country
  4. ORDER BY country;

Filtering grouped results with HAVING

  1. SELECT
  2. active,
  3. COUNT() as c,
  4. MIN(age),
  5. MAX(age)
  6. FROM customers
  7. GROUP BY active
  8. HAVING COUNT() > 0
  9. ORDER BY active DESC;

Sub-queries

The table in the SELECT or JOIN clauses can be replaced with a sub-query.

  1. SELECT * FROM (
  2. SELECT id, customer_name
  3. FROM customers
  4. WHERE age < 30
  5. )
  6. INNER JOIN customer_review
  7. ON customer_review.customerid = customers.id;
  8. SELECT * FROM (
  9. SELECT id, customer_name
  10. FROM customers
  11. WHERE age < 30
  12. ) AS c
  13. INNER JOIN (
  14. SELECT * FROM customer_review
  15. ) AS r
  16. ON r.customerid = c.id;

Note: the context of a sub-query does not propagate outside, e.g. it is not possible to reference a table from a sub-query in the WHERE clause outside of the sub-query.

Basic transactions

Multiple insert and upsert statements can be issued within a single transaction.

Note: The example below won’t work in the current version of the immudb webconsole. The easiest way to tested it is with the ./immuclient exec "..." shell command (make sure to use an escaped \$ value to avoid cutting out part of the price).

  1. BEGIN TRANSACTION
  2. UPSERT INTO products (id, price, product)
  3. VALUES (4, '$5.76', 'Bread');
  4. INSERT INTO orders(productid, customerid)
  5. VALUES(4, 1);
  6. COMMIT;

Time travel

Time travel allows reading data from SQL as if it was in some previous state. The state is indicated by transaction id.

A historical version of a table can be used in SELECT statements using the BEFORE TX clause:

  1. SELECT id, product, price
  2. FROM products BEFORE TX 13;
  3. SELECT id, product, price
  4. FROM products BEFORE TX 13
  5. WHERE id = 2;