Creating a table > Local tables | Manticore Search Manual

Manticore's data types can be split into two categories: full-text fields and attributes.

Table, field, and attribute names can contain ASCII letters (a-z, A-Z), numbers (0-9), underscores (_), and safe non-ASCII UTF-8 characters. An unquoted SQL name must start with an ASCII letter, an underscore, or a non-ASCII UTF-8 character. Numbers are allowed after the first character.

The same base syntax applies to every table type in each mode where that type is supported: real-time, percolate, and distributed tables in RT mode, and real-time, percolate, plain, distributed, and template tables in Plain mode. It also applies to every schema that defines fields or attributes, including the expected document schema of a percolate table and schemas inferred from SQL, CSV/TSV, or XML sources.

Other user-defined SQL object names, including function, plugin, and replication cluster names, follow the same safe UTF-8 rules.

Use backticks around SQL names that begin with a number and contain at least one letter, underscore, or non-ASCII UTF-8 character, and around names that match a reserved SQL keyword. For example, use `2026_архив` or `select`. Configuration-file names are not quoted and may begin with a number. All-numeric identifiers are rejected in every mode, including while loading existing configuration or metadata; rename any such object before upgrading. Backticks do not make arbitrary ASCII punctuation valid; characters such as -, $, spaces, and embedded backticks are not supported in user-defined names.

For compatibility with common log-ingestion schemas, CREATE TABLE and ALTER TABLE also accept the column names @timestamp and @version case-insensitively, with or without backticks. Other user-defined names beginning with @ remain invalid. This exception does not make @ a general identifier character in SQL or configuration-file schemas.

For backward compatibility, Plain-mode configuration loading accepts . and - after the first character in table, field, and attribute names that earlier releases allowed. Do not use this compatibility syntax in new schemas: SQL cannot address every such name consistently, and SQL DDL continues to reject arbitrary punctuation.

Identifiers must be valid UTF-8. Control characters, Unicode whitespace, bidirectional controls, and invisible default-ignorable characters are rejected. This includes non-breaking spaces, zero-width spaces, and zero-width joiners.

Table names are limited to 200 bytes after being encoded as UTF-8 in both RT and Plain modes. Each ASCII character uses one byte, while a non-ASCII character uses two, three, or four bytes. This means a name can contain up to 200 ASCII characters, but fewer non-ASCII characters depending on the characters used. The component after the system. qualifier may use up to 48 additional bytes for shard and other generated suffixes. This qualified namespace is used for internal tables and is also accepted explicitly in SQL; ordinary public logical table names remain limited to 200 bytes. The limit also applies when existing table definitions are loaded, so rename any longer table before upgrading.

In RT mode, the exact logical table name is stored in Manticore's metadata while table files use a bounded portable ASCII basename. This lets byte-distinct names coexist on case- or normalization-insensitive filesystems and avoids Windows reserved filenames. The component mapping does not prevalidate the complete storage path; operating-system path limits still apply, and a later filesystem error reports the failing path and OS error.

For table, field, and attribute names created through SQL, Manticore converts ASCII uppercase letters to lowercase. Non-ASCII characters retain their original spelling. Configuration section names in Plain mode are case-sensitive, including their ASCII letters. Unicode case folding and Unicode normalization are not applied in either mode, so use the exact Unicode spelling consistently.

For example:

Valid unquoted names: title, product_id, user_name_2, товары2026, 商品表, 📦метка
Valid quoted names: `2026_архив`, `select`
Valid SQL compatibility column names: @timestamp, @version
Invalid names: 2title without backticks, -price, user@name, user-name, @user_field, and badname containing a zero-width space

In Plain mode, table names are section names in the configuration file and are written without backticks there. Backticks can still be used when referring to those tables in SQL. For example, a config section can be named таблица2026, while a section named 2026_архив is referenced as `2026_архив` in SQL.

Field-scoped full-text query operators also support non-ASCII UTF-8 field names. For example, MATCH('@название клавиатура') restricts the search to the название field. This also applies to field-scoped queries stored as percolate rules.

Full-text fields:

can be indexed with natural language processing algorithms, therefore can be searched for keywords
cannot be used for sorting or grouping
original document's content can be retrieved
original document's content can be used for highlighting

Full-text fields are represented by the data type text. All other data types are called "attributes".

Attributes are non-full-text values associated with each document that can be used to perform non-full-text filtering, sorting and grouping during a search.

It is often desired to process full-text search results based not only on matching document ID and its rank, but also on a number of other per-document values. For example, one might need to sort news search results by date and then relevance, or search through products within a specified price range, or limit a blog search to posts made by selected users, or group results by month. To do this efficiently, Manticore enables not only full-text fields, but also additional attributes to be added to each document. These attributes can be used to filter, sort, or group full-text matches, or to search only by attributes.

The attributes, unlike full-text fields, are not full-text indexed. They are stored in the table, but it is not possible to search them as full-text.

A good example for attributes would be a forum posts table. Assume that only the title and content fields need to be full-text searchable - but that sometimes it is also required to limit search to a certain author or a sub-forum (i.e., search only those rows that have some specific values of author_id or forum_id); or to sort matches by post_date column; or to group matching posts by month of the post_date and calculate per-group match counts.

‹›

SQL
JSON
PHP
Python
Python-asyncio
Javascript
Java
C#
Rust
config

📋

CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp);

POST /cli -d "CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)"

$table = new \Manticoresearch\Table($client);
$table->setName('forum');
$table->create([
    'title'=>['type'=>'text'],
    'content'=>['type'=>'text'],
    'author_id'=>['type'=>'int'],
    'forum_id'=>['type'=>'int'],
    'post_date'=>['type'=>'timestamp']
]);

utilsApi.sql('CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)')

await utilsApi.sql('CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)')

res = await utilsApi.sql('CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)');

utilsApi.sql("CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)");

utilsApi.Sql("CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)");

utils_api.sql("CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)", Some(true)).await;

table forum
{
    type = rt
    path = forum
    # when configuring fields via config, they are indexed (and not stored) by default
    rt_field = title
    rt_field = content
    # this option needs to be specified for the field to be stored
    stored_fields = title, content
    rt_attr_uint = author_id
    rt_attr_uint = forum_id
    rt_attr_timestamp = post_date
}

This example shows running a full-text query filtered by author_id, forum_id and sorted by post_date.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from forum where author_id=123 and forum_id in (1,3,7) order by post_date desc

POST /search
{
  "table": "forum",
  "query":
  {
    "match_all": {},
    "bool":
    {
      "must":
      [
        { "equals": { "author_id": 123 } },
        { "in": { "forum_id": [1,3,7] } }
      ]
    }
  },
  "sort": [ { "post_date": "desc" } ]
}

$client->search([
        'table' => 'forum',
        'query' =>
        [
            'match_all' => [],
            'bool' => [
                'must' => [
                    'equals' => ['author_id' => 123],
                    'in' => [
                        'forum_id' => [
                            1,3,7
                        ]
                    ]
                ]
            ]
        ],
        'sort' => [
        ['post_date' => 'desc']
    ]
]);

searchApi.search({"table":"forum","query":{"match_all":{},"bool":{"must":[{"equals":{"author_id":123}},{"in":{"forum_id":[1,3,7]}}]}},"sort":[{"post_date":"desc"}]})

await searchApi.search({"table":"forum","query":{"match_all":{},"bool":{"must":[{"equals":{"author_id":123}},{"in":{"forum_id":[1,3,7]}}]}},"sort":[{"post_date":"desc"}]})

res = await searchApi.search({"table":"forum","query":{"match_all":{},"bool":{"must":[{"equals":{"author_id":123}},{"in":{"forum_id":[1,3,7]}}]}},"sort":[{"post_date":"desc"}]});

HashMap<String,Object> filters = new HashMap<String,Object>(){{
    put("must", new HashMap<String,Object>(){{
        put("equals",new HashMap<String,Integer>(){{
            put("author_id",123);
        }});
        put("in",
            new HashMap<String,Object>(){{
                put("forum_id",new int[] {1,3,7});
        }});
    }});
}};
Map<String,Object> query = new HashMap<String,Object>();
query.put("match_all",null);
query.put("bool",filters);
SearchRequest searchRequest = new SearchRequest();
searchRequest.setTable("forum");
searchRequest.setQuery(query);
searchRequest.setSort(new ArrayList<Object>(){{
    add(new HashMap<String,String>(){{ put("post_date","desc");}});
}});
SearchResponse searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
var boolFilter = new BoolFilter();
boolFilter.Must = new List<Object> {
    new EqualsFilter("author_id", 123),
    new InFilter("forum_id", new List<Object> {1,3,7})
};
searchRequest.AttrFilter = boolFilter;
searchRequest.Sort = new List<Object> { new SortOrder("post_date", SortOrder.OrderEnum.Desc) };
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut sort = HashMap::new();
sort.insert("post_date".to_string(), serde_json::json!("desc"));
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    sort: serde_json::json!(sort)
    ..Default::default()
};
let search_res = search_api.search(search_req).await;

Manticore supports two types of attribute storages:

row-wise - traditional storage available in Manticore Search out of the box
columnar - provided by Manticore Columnar Library

As can be understood from their names, they store data differently. The traditional row-wise storage:

stores attributes uncompressed
all attributes of the same document are stored in one row close to each other
rows are stored one by one
accessing attributes is basically done by just multiplying the row ID by the stride (length of a single vector) and getting the requested attribute from the calculated memory location. It gives very low random access latency.
attributes have to be in memory to get acceptable performance, otherwise due to the row-wise nature of the storage Manticore may have to read from disk too much unneeded data which is in many cases suboptimal.

With the columnar storage:

each attribute is stored independently of all other attributes in its separate "column"
storage is split into blocks of 65536 entries
the blocks are stored compressed. This often allows storing just a few distinct values instead of storing all of them like in the row-wise storage. High compression ratio allows reading from disk faster and makes the memory requirement much lower
when data is indexed, storage scheme is selected for each block independently. For example, if all values in a block are the same, it gets "const" storage and only one value is stored for the whole block. If there are less than 256 unique values per block, it gets "table" storage and stores indexes to a table of values instead of the values themselves
search in a block can be early rejected if it's clear the requested value is not present in the block.

The columnar storage was designed to handle large data volume that does not fit into RAM, so the recommendations are:

if you have enough memory for all your attributes you will benefit from the row-wise storage
otherwise, the columnar storage can still give you decent performance with a much lower memory footprint which will allow you to store much more documents in your table

The traditional row-wise storage is the default, so if you want everything to be stored in a row-wise fashion, you don't need to do anything when you create a table.

To enable the columnar storage you need to:

specify engine='columnar' in CREATE TABLE to make all attributes of the table columnar. Then, if you want to keep a specific attribute row-wise, you need to add engine='rowwise' when you declare it. For example:
```
create table tbl(title text, type int, price float engine='rowwise') engine='columnar'
```

specify engine='columnar' for a specific attribute in CREATE TABLE to make it columnar. For example:

create table tbl(title text, type int, price float engine='columnar');

create table tbl(title text, type int, price float engine='columnar') engine='rowwise';

in the plain mode you need to list attributes you want to be columnar in columnar_attrs.

Below is the list of data types supported by Manticore Search:

Every table has a document ID. It must be unique and cannot be updated. By default, document IDs are unsigned 64-bit values. Explicit numeric document IDs must be non-zero; negative document IDs are not allowed. Real-time tables can instead use UUID document IDs, as described in UUID document IDs.

For a numeric document ID, you can declare id bigint in the CREATE TABLE schema or omit it and let Manticore add it automatically. In the MySQL/SQL interface, a numeric ID is exposed as a signed 64-bit bigint, so large unsigned ID values may appear as negative numbers there.

mysql> CREATE TABLE tbl(id bigint, content text);
DESC tbl;
+---------+--------+----------------+
| Field   | Type   | Properties     |
+---------+--------+----------------+
| id      | bigint |                |
| content | text   | indexed stored |
+---------+--------+----------------+
2 rows in set (0.00 sec)

You can also omit specifying ID at all, it will be enabled automatically.

mysql> CREATE TABLE tbl(content text);
DESC tbl;
+---------+--------+----------------+
| Field   | Type   | Properties     |
+---------+--------+----------------+
| id      | bigint |                |
| content | text   | indexed stored |
+---------+--------+----------------+
2 rows in set (0.00 sec)

Auto-ID generation depends on the table and ID type. RT and PQ tables with numeric IDs can generate an ID when it is omitted from an insert or replace request, or when 0 is used. An RT table with id uuid generates a UUID only when id is omitted. Plain tables built from external sources do not support automatic ID generation; their source data must provide explicit, unique, non-zero unsigned 64-bit document IDs.

When working with numeric document IDs, it's important to know that unsigned 64-bit values are handled differently depending on the interface:

MySQL/SQL interface:

IDs greater than 2^63-1 will appear as negative numbers.
When filtering by such large IDs, you must use their signed representation.
This signed representation is only for displaying or filtering existing large IDs; negative IDs are not accepted when inserting or indexing documents.
Use the UINT64() function to view the actual unsigned value.

JSON/HTTP interface:

IDs are always displayed as their original unsigned values, regardless of size.
Both signed and unsigned representations can be used for filtering existing large IDs.
Insert operations accept the full unsigned 64-bit range, but negative id values are rejected.

For example, let's create a table and insert some values around 2^63:

mysql> create table t(id_text string);
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t values(9223372036854775807, '2 ^ 63 - 1'),(9223372036854775808, '2 ^ 63');
Query OK, 2 rows affected (0.00 sec)

Some IDs appear as negative numbers in the results because they exceed 2^63-1. However, using UINT64(id) can reveal their actual unsigned values:

mysql> select *, uint64(id) from t;
+----------------------+------------+---------------------+
| id                   | id_text    | uint64(id)          |
+----------------------+------------+---------------------+
|  9223372036854775807 | 2 ^ 63 - 1 | 9223372036854775807 |
| -9223372036854775808 | 2 ^ 63     | 9223372036854775808 |
+----------------------+------------+---------------------+
2 rows in set (0.00 sec)
--- 2 out of 2 results in 0ms ---

For querying documents with IDs less than 2^63, you can use the unsigned value directly:

mysql> select * from t where id = 9223372036854775807;
+---------------------+------------+
| id                  | id_text    |
+---------------------+------------+
| 9223372036854775807 | 2 ^ 63 - 1 |
+---------------------+------------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

However, for IDs starting from 2^63, you need to use the signed value:

mysql> select * from t where id = -9223372036854775808;
+----------------------+---------+
| id                   | id_text |
+----------------------+---------+
| -9223372036854775808 | 2 ^ 63  |
+----------------------+---------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

If you use an unsigned value instead, you will get an error:

mysql> select * from t where id = 9223372036854775808;
ERROR 1064 (42000): number 9223372036854775808 is out of range [-9223372036854775808..9223372036854775807]

Values that do not fit within 64 bits will trigger a similar error:

mysql> select * from t where id = -9223372036854775809;
ERROR 1064 (42000): number -9223372036854775809 is out of range [-9223372036854775808..9223372036854775807]

The behavior differences between MySQL/SQL and JSON/HTTP interfaces become more apparent with very large document IDs. Here's a comprehensive example:

MySQL/SQL interface:

mysql> drop table if exists t; create table t; insert into t values(17581446260360033510);
Query OK, 0 rows affected (0.01 sec)
mysql> select * from t;
+---------------------+
| id                  |
+---------------------+
| -865297813349518106 |
+---------------------+
mysql> select *, uint64(id) from t;
+---------------------+----------------------+
| id                  | uint64(id)           |
+---------------------+----------------------+
| -865297813349518106 | 17581446260360033510 |
+---------------------+----------------------+
mysql> select * from t where id = -865297813349518106;
+---------------------+
| id                  |
+---------------------+
| -865297813349518106 |
+---------------------+
mysql> select * from t where id = 17581446260360033510;
ERROR 1064 (42000): number 17581446260360033510 is out of range [-9223372036854775808..9223372036854775807]

JSON/HTTP interface:

# Search returns the original unsigned value
curl -s 0:9308/search -d '{"table": "t"}'
{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 1,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 17581446260360033510,
        "_score": 1,
        "_source": {}
      }
    ]
  }
}
# Both signed and unsigned values work for filtering the same stored ID
curl -s 0:9308/search -d '{"table": "t", "query": {"equals": {"id": 17581446260360033510}}}'
curl -s 0:9308/search -d '{"table": "t", "query": {"equals": {"id": -865297813349518106}}}'
# Insert with maximum unsigned 64-bit value
curl -s 0:9308/insert -d '{"table": "t", "id": 18446744073709551615, "doc": {}}'

This means when working with large document IDs:

MySQL interface requires using the signed representation for queries but can display the unsigned value with UINT64()
JSON interface consistently uses unsigned values for display and accepts both representations for filtering

Real-time tables can use UUID document IDs with id uuid. Explicit IDs must be strings in the 36-character 8-4-4-4-12 hexadecimal format, for example 550e8400-e29b-41d4-a716-446655440000. Manticore accepts UUID versions 1 through 8 and RFC variants 8, 9, a, and b. Uppercase letters are accepted and normalized to lowercase.

Omit id to generate a UUID automatically. This works with SQL INSERT and REPLACE, native JSON insert and replace requests, and Elasticsearch-compatible _bulk index and create operations. Generated IDs use a UUIDv8-style layout and have the same uniqueness guarantees as numeric auto-IDs. They are not random UUIDv4 values and must not be used as cryptographic secrets.

SQL returns UUID IDs as strings. For UUID-ID tables, native JSON write responses use key name id, while JSON search and Elasticsearch-compatible responses use _id.

UUID IDs can be used in equality and IN filters and to identify documents in REPLACE, UPDATE, and DELETE. INSERT rejects an ID that already exists; use REPLACE to overwrite the document with that ID. After an INSERT or REPLACE on a UUID-ID table, LAST_INSERT_ID() and @@session.last_insert_id return the UUID IDs of the affected documents.

Limitations:

Only the id column can use the uuid type; regular attributes cannot be declared as uuid.
UUID document IDs are supported only for real-time tables, including columnar and replicated real-time tables. They are not supported for plain (indexer-created), percolate/PQ, or shard tables.
ALTER TABLE cannot convert an existing table to or from id uuid.
Range filters (<, <=, >, >=) and numeric or arithmetic expressions on UUID id are not supported.
Unlike numeric-ID tables, UUID-ID tables do not treat 0 as an auto-ID marker.

‹›

SQL

📋

CREATE TABLE products_uuid(id uuid, title text, price int);
INSERT INTO products_uuid(id, title, price) VALUES('550e8400-e29b-41d4-a716-446655440000', 'Crossbody Bag', 19);
INSERT INTO products_uuid(title, price) VALUES('Generated UUID Bag', 29);
SELECT id, price FROM products_uuid WHERE id='550e8400-e29b-41d4-a716-446655440000';

‹›

Response

Query OK, 0 rows affected (0.00 sec)
Query OK, 1 rows affected (0.00 sec)
Query OK, 1 rows affected (0.00 sec)
+--------------------------------------+-------+
| id                                   | price |
+--------------------------------------+-------+
| 550e8400-e29b-41d4-a716-446655440000 |    19 |
+--------------------------------------+-------+
1 row in set (0.00 sec)

General syntax:

string|text [stored|attribute] [indexed]

Properties:

indexed - full-text indexed (can be used in full-text queries)
stored - stored in a docstore (stored on disk, not in RAM, lazy read)
attribute - makes it a string attribute (can sort/group by it)

Specifying at least one property overrides all the default ones (see below), i.e., if you decide to use a custom combination of properties, you need to list all the properties you want.

No properties specified:

string and text are aliases, but if you don't specify any properties, they by default mean different things:

just string by default means attribute (see details below).
just text by default means stored + indexed (see details below).

The text (just text or text/string indexed) data type forms the full-text part of the table. Text fields are indexed and can be searched for keywords.

Text is passed through an analyzer pipeline that converts the text to words, applies morphology transformations, etc. Eventually, a full-text table (a special data structure that enables quick searches for a keyword) gets built from that text.

Full-text fields can only be used in the MATCH() clause and cannot be used for sorting or aggregation. Words are stored in an inverted index along with references to the fields they belong to and positions in the field. This allows searching a word inside each field and using advanced operators like proximity. By default, the original text of the fields is both indexed and stored in document storage. It means that the original text can be returned with the query results and used in search result highlighting.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text);

POST /cli -d "CREATE TABLE products(title text)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text']
]);

utilsApi.sql('CREATE TABLE products(title text)')

await utilsApi.sql('CREATE TABLE products(title text)')

res = await utilsApi.sql('CREATE TABLE products(title text)');

utilsApi.sql("CREATE TABLE products(title text)");

utilsApi.Sql("CREATE TABLE products(title text)");

utils_api.sql("CREATE TABLE products(title text)", Some(true)).await;

table products
{
    type = rt
    path = products
    # when configuring fields via config, they are indexed (and not stored) by default
    rt_field = title
    # this option needs to be specified for the field to be stored
    stored_fields = title
}

This behavior can be overridden by explicitly specifying that the text is only indexed.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text indexed);

POST /cli -d "CREATE TABLE products(title text indexed)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text','options'=>['indexed']]
]);

utilsApi.sql('CREATE TABLE products(title text indexed)')

await utilsApi.sql('CREATE TABLE products(title text indexed)')

res = await utilsApi.sql('CREATE TABLE products(title text indexed)');

utilsApi.sql("CREATE TABLE products(title text indexed)");

utilsApi.Sql("CREATE TABLE products(title text indexed)");

utils_api.sql("CREATE TABLE products(title text indexed)", Some(true)).await;

table products
{
    type = rt
    path = products
    # when configuring fields via config, they are indexed (and not stored) by default
    rt_field = title
}

Fields are named, and you can limit your searches to a single field (e.g. search through "title" only) or a subset of fields (e.g. "title" and "abstract" only). You can have up to 256 full-text fields.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from products where match('@title first');

POST /search
{
    "table": "products",
    "query":
    {
        "match": { "title": "first" }
    }
}

$table->setName('products')->search('@title')->get();

searchApi.search({"table":"products","query":{"match":{"title":"first"}}})

await searchApi.search({"table":"products","query":{"match":{"title":"first"}}})

res = await searchApi.search({"table":"products","query":{"match":{"title":"first"}}});

utilsApi.sql("CREATE TABLE products(title text indexed)");

utilsApi.Sql("CREATE TABLE products(title text indexed)");

utils_api.sql("CREATE TABLE products(title text indexed)", Some(true)).await;

Unlike full-text fields, string attributes (just string or string/text attribute) are stored as they are received and cannot be used in full-text searches. Instead, they are returned in results, can be used in the WHERE clause for comparison filtering or REGEX, and can be used for sorting and aggregation. In general, it's not recommended to store large texts in string attributes, but use string attributes for metadata like names, titles, tags, keys.

If you want to also index the string attribute, you can specify both as string attribute indexed. It will allow full-text searching and works as an attribute.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, keys string);

POST /cli -d "CREATE TABLE products(title text, keys string)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'keys'=>['type'=>'string']
]);

utilsApi.sql('CREATE TABLE products(title text, keys string)')

await utilsApi.sql('CREATE TABLE products(title text, keys string)')

res = await utilsApi.sql('CREATE TABLE products(title text, keys string)');

utilsApi.sql("CREATE TABLE products(title text, keys string)");

utilsApi.Sql("CREATE TABLE products(title text, keys string)");

utils_api.sql("CREATE TABLE products(title text, keys string)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_string = keys
}

Manticore doesn't have a dedicated field type for binary data, but you can store it safely by using base64 encoding and the text stored or string stored field types (which are synonyms). If you don't encode the binary data, parts of it may get lost — for example, Manticore trims the end of a string if it encounters a null-byte.

Here is an example where we encode the ls command using base64, store it in Manticore, and then decode it to verify that the MD5 checksum remains unchanged:

‹›

Example

Example

📋

# md5sum /bin/ls
43d1b8a7ccda411118e2caba685f4329  /bin/ls
# encoded_data=`base64 -i /bin/ls `
# mysql -P9306 -h0 -e "drop table if exists test; create table test(data text stored); insert into test(data) values('$encoded_data')"
# mysql -P9306 -h0 -NB -e "select data from test" | base64 -d > /tmp/ls | md5sum
43d1b8a7ccda411118e2caba685f4329  -

Integer type allows storing 32 bit unsigned integer values.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, price int);

POST /cli -d "CREATE TABLE products(title text, price int)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'int']
]);

utilsApi.sql('CREATE TABLE products(title text, price int)')

await utilsApi.sql('CREATE TABLE products(title text, price int)')

res = await utilsApi.sql('CREATE TABLE products(title text, price int)');

utilsApi.sql("CREATE TABLE products(title text, price int)");

utilsApi.Sql("CREATE TABLE products(title text, price int)");

utils_api.sql("CREATE TABLE products(title text, price int)", Some(true)).await;

table products
{
    type = rt
    path = products

    rt_field = title
    stored_fields = title

    rt_attr_uint = type
}

Integers can be stored in shorter sizes than 32-bit by specifying a bit count. For example, if we want to store a numeric value which we know is not going to be bigger than 8, the type can be defined as bit(3). Bitcount integers perform slower than the full-size ones, but they require less RAM. They are saved in 32-bit chunks, so in order to save space, they should be grouped at the end of attribute definitions (otherwise a bitcount integer between 2 full-size integers will occupy 32 bits as well).

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, flags bit(3), tags bit(2) );

POST /cli -d "CREATE TABLE products(title text, flags bit(3), tags bit(2))"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'flags'=>['type'=>'bit(3)'],
    'tags'=>['type'=>'bit(2)']
]);

utilsApi.sql('CREATE TABLE products(title text, flags bit(3), tags bit(2) ')

await utilsApi.sql('CREATE TABLE products(title text, flags bit(3), tags bit(2) ')

res = await utilsApi.sql('CREATE TABLE products(title text, flags bit(3), tags bit(2) ');

utilsApi.sql("CREATE TABLE products(title text, flags bit(3), tags bit(2)");

utilsApi.Sql("CREATE TABLE products(title text, flags bit(3), tags bit(2)");

utils_api.sql("CREATE TABLE products(title text, flags bit(3), tags bit(2)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_uint = flags:3
    rt_attr_uint = tags:2
}

Big integers (bigint) are 64-bit wide signed integers.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, price bigint );

POST /cli -d "CREATE TABLE products(title text, price bigint)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'bigint']
]);

utilsApi.sql('CREATE TABLE products(title text, price bigint )')

await utilsApi.sql('CREATE TABLE products(title text, price bigint )')

res = await utilsApi.sql('CREATE TABLE products(title text, price bigint )');

utilsApi.sql("CREATE TABLE products(title text, price bigint )");

utilsApi.Sql("CREATE TABLE products(title text, price bigint )");

utils_api.sql("CREATE TABLE products(title text, price bigint )", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_bigint = type
}

Declares a boolean attribute. It's equivalent to an integer attribute with bit count of 1.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, sold bool );

POST /cli -d "CREATE TABLE products(title text, sold bool)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'sold'=>['type'=>'bool']
]);

utilsApi.sql('CREATE TABLE products(title text, sold bool )')

await utilsApi.sql('CREATE TABLE products(title text, sold bool )')

res = await utilsApi.sql('CREATE TABLE products(title text, sold bool )');

utilsApi.sql("CREATE TABLE products(title text, sold bool )");

utilsApi.Sql("CREATE TABLE products(title text, sold bool )");

utils_api.sql("CREATE TABLE products(title text, sold bool )", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_bool = sold
}

The timestamp type represents Unix timestamps, which are stored as 32-bit integers. Unlike basic integers, the timestamp type allows the use of time and date functions. Conversion from string values follows these rules:

Numbers without delimiters, at least 10 characters long, are converted to timestamps as is.
%Y-%m-%dT%H:%M:%E*S%Z
%Y-%m-%d'T'%H:%M:%S%Z
%Y-%m-%dT%H:%M:%E*S
%Y-%m-%dT%H:%M:%s
%Y-%m-%dT%H:%M
%Y-%m-%dT%H
%Y-%m-%d
%Y-%m
%Y

The meanings of these conversion specifiers are detailed in the strptime manual, except for %E*S, which stands for milliseconds.

Note that auto-conversion of timestamps is not supported in plain tables.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, date timestamp);

POST /cli -d "CREATE TABLE products(title text, date timestamp)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'date'=>['type'=>'timestamp']
]);

utilsApi.sql('CREATE TABLE products(title text, date timestamp)')

await utilsApi.sql('CREATE TABLE products(title text, date timestamp)')

res = await utilsApi.sql('CREATE TABLE products(title text, date timestamp)');

utilsApi.sql("CREATE TABLE products(title text, date timestamp)");

utilsApi.Sql("CREATE TABLE products(title text, date timestamp)");

utils_api.sql("CREATE TABLE products(title text, date timestamp)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_timestamp = date
}

Real numbers are stored as 32-bit IEEE 754 single precision floats.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, coeff float);

POST /cli -d "CREATE TABLE products(title text, coeff float)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'coeff'=>['type'=>'float']
]);

utilsApi.sql('CREATE TABLE products(title text, coeff float)')

await utilsApi.sql('CREATE TABLE products(title text, coeff float)')

res = await utilsApi.sql('CREATE TABLE products(title text, coeff float)');

utilsApi.sql("CREATE TABLE products(title text, coeff float)");

utilsApi.Sql("CREATE TABLE products(title text, coeff float)");

utils_api.sql("CREATE TABLE products(title text, coeff float)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_float = coeff
}

Unlike integer types, comparing two floating-point numbers for equality is not recommended due to potential rounding errors. A more reliable approach is to use a near-equal comparison, by checking the absolute error margin.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select abs(a-b)<=0.00001 from products

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "expressions": { "eps": "abs(a-b)" }
}

$table->setName('products')->search('')->expression('eps','abs(a-b)')->get();

searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"eps":"abs(a-b)"}})

await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"eps":"abs(a-b)"}})

res = await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"eps":"abs(a-b)"}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("ebs","abs(a-b)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Expressions = new List<Object>{
    new Dictionary<string, string> { {"ebs", "abs(a-b)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("ebs".to_string(), serde_json::json!("abs(a-b)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Another alternative, which can also be used to perform IN(attr,val1,val2,val3) is to compare floats as integers by choosing a multiplier factor and convert the floats to integers in operations. The following example illustrates modifying IN(attr,2.0,2.5,3.5) to work with integer values.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select in(ceil(attr*100),200,250,350) from products

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "expressions": { "inc": "in(ceil(attr*100),200,250,350)" }
}

$table->setName('products')->search('')->expression('inc','in(ceil(attr*100),200,250,350)')->get();

searchApi.search({"table":"products","query":{"match_all":{}}},"expressions":{"inc":"in(ceil(attr*100),200,250,350)"}})

await searchApi.search({"table":"products","query":{"match_all":{}}},"expressions":{"inc":"in(ceil(attr*100),200,250,350)"}})

res = await searchApi.search({"table":"products","query":{"match_all":{}}},"expressions":{"inc":"in(ceil(attr*100),200,250,350)"}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("inc","in(ceil(attr*100),200,250,350)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Expressions = new List<Object> {
    new Dictionary<string, string> { {"ebs", "in(ceil(attr*100),200,250,350)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("ebs".to_string(), serde_json::json!("in(ceil(attr*100),200,250,350)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Float values in Manticore are displayed with precision to ensure they reflect the exact stored value. This approach was introduced to prevent precision loss, especially for cases like geographical coordinates, where rounding to 6 decimal places caused inaccuracies.

Now, Manticore first outputs a number with 6 digits, then parses and compares it to the original value. If they don't match, additional digits are added until they do.

For example, if a float value was inserted as 19.45, Manticore will display it as 19.450001 to accurately represent the stored value.

‹›

Example

Example

📋

insert into t(id, f) values(1, 19.45)
--------------
Query OK, 1 row affected (0.02 sec)
--------------
select * from t
--------------
+------+-----------+
| id   | f         |
+------+-----------+
|    1 | 19.450001 |
+------+-----------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

This data type allows for the storage of JSON objects, which is particularly useful for handling schema-less data. When defining JSON values, ensure that the opening and closing curly braces { and } are included for objects, or square brackets [ and ] for arrays. While JSON is not supported by columnar storage, it can be stored in traditional row-wise storage. It's worth noting that both storage types can be combined within the same table.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, data json);

POST /cli -d "CREATE TABLE products(title text, data json)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'data'=>['type'=>'json']
]);

utilsApi.sql('CREATE TABLE products(title text, data json)')

await utilsApi.sql('CREATE TABLE products(title text, data json)')

res = await utilsApi.sql('CREATE TABLE products(title text, data json)');

utilsApi.sql("CREATE TABLE products(title text, data json)");

utilsApi.Sql("CREATE TABLE products(title text, data json)");

utils_api.sql("CREATE TABLE products(title text, data json)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_json = data
}

JSON properties can be used in most operations. There are also special functions such as ALL(), ANY(), GREATEST(), LEAST() and INDEXOF() that allow traversal of property arrays.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select indexof(x>2 for x in data.intarray) from products

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "expressions": { "idx": "indexof(x>2 for x in data.intarray)" }
}

$table->setName('products')->search('')->expression('idx','indexof(x>2 for x in data.intarray)')->get();

searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"idx":"indexof(x>2 for x in data.intarray)"}})

await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"idx":"indexof(x>2 for x in data.intarray)"}})

res = await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"idx":"indexof(x>2 for x in data.intarray)"}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("idx","indexof(x>2 for x in data.intarray)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Expressions = new List<Object> {
    new Dictionary<string, string> { {"idx", "indexof(x>2 for x in data.intarray)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("idx".to_string(), serde_json::json!("indexof(x>2 for x in data.intarray)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Text properties are treated the same as strings, so it's not possible to use them in full-text match expressions. However, string functions such as REGEX() can be used.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select regex(data.name, 'est') as c from products where c>0

POST /search
{
  "table": "products",
  "query":
  {
    "match_all": {},
    "range": { "c": { "gt": 0 } } }
  },
  "expressions": { "c": "regex(data.name, 'est')" }
}

$table->setName('products')->search('')->expression('idx',"regex(data.name, 'est')")->filter('c','gt',0)->get();

searchApi.search({"table":"products","query":{"match_all":{},"range":{"c":{"gt":0}}}},"expressions":{"c":"regex(data.name, 'est')"}})

await searchApi.search({"table":"products","query":{"match_all":{},"range":{"c":{"gt":0}}}},"expressions":{"c":"regex(data.name, 'est')"}})

res = await searchApi.search({"table":"products","query":{"match_all":{},"range":{"c":{"gt":0}}}},"expressions":{"c":"regex(data.name, 'est')"}}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
query.put("range", new HashMap<String,Object>(){{
    put("c", new HashMap<String,Object>(){{
        put("gt",0);
    }});
}});
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("idx","indexof(x>2 for x in data.intarray)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
var rangeFilter = new RangeFilter("c");
rangeFilter.Gt = 0;
searchRequest.AttrFilter = rangeFilter;
searchRequest.Expressions = new List<Object> {
    new Dictionary<string, string> { {"idx", "indexof(x>2 for x in data.intarray)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("idx".to_string(), serde_json::json!("indexof(x>2 for x in data.intarray)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

In the case of JSON properties, enforcing data type may be required for proper functionality in certain situations. For example, when working with float values, DOUBLE() must be used for proper sorting.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from products order by double(data.myfloat) desc

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "sort": [ { "double(data.myfloat)": { "order": "desc"} } ]
}

$table->setName('products')->search('')->sort('double(data.myfloat)','desc')->get();

searchApi.search({"table":"products","query":{"match_all":{}}},"sort":[{"double(data.myfloat)":{"order":"desc"}}]})

await searchApi.search({"table":"products","query":{"match_all":{}}},"sort":[{"double(data.myfloat)":{"order":"desc"}}]})

res = await searchApi.search({"table":"products","query":{"match_all":{}}},"sort":[{"double(data.myfloat)":{"order":"desc"}}]});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
searchRequest.setSort(new ArrayList<Object>(){{
    add(new HashMap<String,String>(){{ put("double(data.myfloat)",new HashMap<String,String>(){{ put("order","desc");}});}});
}});
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Sort = new List<Object> {
    new SortOrder("double(data.myfloat)", SortOrder.OrderEnum.Desc)
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut sort = HashMap::new();
sort.insert("double(data.myfloat)".to_string(), serde_json::json!("desc"));
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    sort: serde_json::json!(sort)
    ..Default::default()
};
let search_res = search_api.search(search_req).await;

Float vector attributes allow storing variable-length lists of floats, primarily used for machine learning applications and similarity searches. This type differs from multi-valued attributes (MVAs) in several important ways:

Preserves the exact order of values (unlike MVAs which may reorder)
Retains duplicate values (unlike MVAs which deduplicate)
No additional processing during insertion (unlike MVAs which sort and deduplicate)

Important: The float_vector data type is not compatible with the Auto schema mechanism.

Currently only supported in real-time tables (not in plain tables)
Not supported in other functions or expressions
Cannot be used in regular filters or sorting

When you configure a float_vector attribute with KNN settings, you enable vector similarity search capabilities. This allows you to perform k-nearest neighbor searches to find similar documents based on vector distance.

What you can do:

Perform KNN (k-nearest neighbor) vector searches to find similar documents
Build semantic search, recommendations, and AI-powered features
Use auto embeddings to automatically generate vectors from text

What you cannot do:

UPDATE float_vector values (you must use REPLACE instead)
Use float vectors in regular filters or sorting
Filter by float_vector values except through vector search operations

When creating a table with float_vector attributes for KNN search, you can specify the following parameters:

Required parameters:

KNN_TYPE: Currently only 'hnsw' is supported
KNN_DIMS: Number of dimensions in the vectors (required for manual vector insertion, omitted when using MODEL_NAME)
HNSW_SIMILARITY: Distance function - 'l2', 'ip' (inner product), or 'cosine'

Optional parameters:

HNSW_M: Maximum connections in the graph (default: 16)
HNSW_EF_CONSTRUCTION: Construction time/accuracy trade-off (default: 200)

Chunking parameters (when using MODEL_NAME, see Chunking strategies):

CHUNK_STRATEGY: how a document becomes vectors: 'truncate' (default), 'mean', 'fixed', 'recursive' or 'sentence'. The last three produce several vectors per document and require a float_vector_array column.
MAX_TOKENS: chunk size in tokens; 0 (default) uses the model's own limit
OVERLAP_TOKENS: tokens shared between consecutive chunks; requires an explicit non-zero MAX_TOKENS; a large overlap is reduced so chunks still advance
MAX_CHUNKS: ceiling on vectors per document; 0 (default) means unlimited

Auto-embeddings parameters (when using MODEL_NAME):

MODEL_NAME: The embedding model to use (e.g., 'Xenova/all-MiniLM-L6-v2' for the fast ONNX path, 'sentence-transformers/all-MiniLM-L6-v2', or 'openai/text-embedding-ada-002')
FROM: Comma-separated list of field names to use for embedding generation, or empty string '' to use all text/string fields
API_KEY: API key for API-based models (OpenAI, Voyage, Jina)

For more details on setting up float vectors and using them in searches, see KNN search.

The most convenient way to work with float vectors is using auto embeddings. This feature automatically generates embeddings from your text data using machine learning models, eliminating the need to manually compute and insert vectors.

Simplified workflow: Just insert text, embeddings are generated automatically
No manual vector computation: No need to run separate embedding models
Consistent embeddings: Same model ensures consistent vector representations
Multiple model support: Choose from ONNX models on Hugging Face (recommended — runs on Manticore's fast ONNX Runtime backend), sentence-transformers, Qwen embedding models, OpenAI, Voyage, and Jina models
Flexible field selection: Control which fields are used for embedding generation

When creating a table with auto embeddings, specify these additional parameters:

MODEL_NAME: The embedding model to use for automatic vector generation
FROM: Which fields to use for embedding generation (empty string means all text/string fields)
API_KEY: Required for remote models (OpenAI, Voyage, Jina). The API key is validated during table creation by making a real API request.
API_URL: Optional. Custom API endpoint URL. If not specified, uses the default provider endpoint (e.g., https://api.openai.com/v1/embeddings for OpenAI).
API_TIMEOUT: Optional. HTTP timeout in seconds for API requests. Default is 10 seconds. Set to '0' to use the default timeout. Applies to both validation requests during table creation and embedding generation during INSERT operations.
MAX_INPUT_TOKENS: Optional. Caps the number of tokens taken from each input text before it is embedded; longer texts are truncated. '0' (default) means the model's own context limit. Long-context models such as Qwen/Qwen3-Embedding-0.6B accept up to 32,768 tokens, and embedding time on CPU grows superlinearly with input length (a 5 KB document can take minutes), so set a cap (for example '512') when the text fields may contain long or unbounded content. Applies to local models; the setting can be changed later with ALTER TABLE ... MODIFY COLUMN ... MAX_INPUT_TOKENS='...' without re-embedding existing rows.

For remote models, MODEL_NAME can use either the legacy provider/model form or the explicit provider:model form. Use provider:model with API_URL when you want the part after : to be forwarded to a custom provider-compatible endpoint exactly as written.

Supported embedding models:

ONNX (recommended): Any Hugging Face model that ships an .onnx file — e.g. Xenova/all-MiniLM-L6-v2, Xenova/all-MiniLM-L12-v2, Xenova/bge-small-en-v1.5, Xenova/multilingual-e5-small. No API key needed. Runs on Manticore's fast ONNX Runtime backend (~14× faster than the SentenceTransformers path on the same hardware — see 14× faster embeddings). Both Xenova and onnx-models publish a lot of ONNX-converted models; for embeddings, look for ones tagged with the feature-extraction task.
Sentence Transformers: Any suitable BERT-based Hugging Face model (e.g., sentence-transformers/all-MiniLM-L6-v2) — no API key needed. Still supported; use this if the model you want isn't published as ONNX.
Qwen local embeddings: Qwen embedding models such as Qwen/Qwen3-Embedding-0.6B — no API key needed. Manticore downloads the model when you create the table.
OpenAI, Voyage, Jina: Remote embedding models (e.g., openai/text-embedding-ada-002, openai:text-embedding-ada-002, voyage/voyage-3.5-lite, jina/jina-embeddings-v2-base-en) - require API_KEY='***' parameter. Optionally specify API_URL='<CUSTOM_URL>' to use a custom API endpoint, and API_TIMEOUT='<SECONDS>' to configure HTTP timeout (default is 10 seconds).

‹›

SQL
JSON

📋

Using a local ONNX model — recommended, runs on the fast ONNX path (no API key needed)

CREATE TABLE products (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='Xenova/all-MiniLM-L6-v2' FROM='title'
);

Using a sentence-transformers model (no API key needed; runs on the Candle path — use ONNX above when available)

CREATE TABLE products_st (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='title'
);

Using Qwen local embeddings (no API key needed)

CREATE TABLE products_qwen (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='Qwen/Qwen3-Embedding-0.6B' FROM='title'
);

Using OpenAI model (requires API_KEY parameter)

CREATE TABLE products_openai (
    title TEXT,
    content TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine'
    MODEL_NAME='openai/text-embedding-ada-002' FROM='title,content' API_KEY='<OPENAI_API_KEY>'
);

Using OpenAI with custom API URL and timeout (optional)

CREATE TABLE products_openai_custom (
    title TEXT,
    content TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine'
    MODEL_NAME='openai:text-embedding-ada-002' FROM='title,content'
    API_KEY='***' API_URL='https://custom-api.example.com/v1/embeddings' API_TIMEOUT='30'
);

Using OpenRouter with a provider-qualified model ID

CREATE TABLE products_openrouter (
    title TEXT,
    content TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine'
    MODEL_NAME='openai:openai/text-embedding-ada-002' FROM='title,content'
    API_KEY='***' API_URL='https://openrouter.ai/api/v1/embeddings' API_TIMEOUT='30'
);

Using all text fields for embeddings (FROM is empty)

CREATE TABLE products_all_fields (
    title TEXT,
    description TEXT,
    tags TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='Xenova/all-MiniLM-L6-v2' FROM=''
);

The FROM parameter controls which fields are used for embedding generation:

Specific fields: FROM='title' - only the title field is used
Multiple fields: FROM='title,description' - both title and description are concatenated and used
All text fields: FROM='' (empty) - all text (full-text field) and string (string attribute) fields in the table are used
Manual override: Even when MODEL_NAME is configured, you can still provide your own vector in INSERT/REPLACE
Empty vectors: You can insert () to skip embedding generation for that row; Manticore stores an all-zero vector with the model's dimension

When using auto embeddings, you have three insert modes:

Omit the vector column and let Manticore generate the embedding from the fields listed in FROM
Provide your own vector explicitly to override auto generation for that row
Provide () to skip generation and store an all-zero vector instead

-- Insert text data - embeddings generated automatically
INSERT INTO products (title, description) VALUES 
('smartphone', 'latest mobile device with camera'),
('laptop computer', 'portable workstation for developers');
-- Insert with a user-provided vector - no auto generation for this row
INSERT INTO products (title, embedding_vector) VALUES
('machine learning artificial intelligence', (0.653448,0.192478,0.017971,0.339821));
-- Insert with empty vector - no auto generation, stores a zero vector
INSERT INTO products (title, description, embedding_vector) VALUES
('no-vector item', 'this item has no embedding', ());

() is useful when you want to keep a row without generating an embedding immediately. Internally, the value is stored as a zero-filled vector, so it should be treated as "no meaningful embedding yet" rather than as a semantic vector. If you later run ALTER TABLE ... REBUILD EMBEDDINGS, that row is rebuilt too; REBUILD EMBEDDINGS does not skip rows just because their current vector is all zeros.

Alternatively, you can manually insert pre-computed vector data. This requires you to compute the vectors yourself using external tools or models, then insert them into Manticore.

Important: When using HNSW_SIMILARITY='cosine', vectors are automatically normalized upon insertion to unit vectors (vectors with a mathematical length/magnitude of 1.0). This normalization preserves the direction of the vector while standardizing its length, which is required for efficient cosine similarity calculations. This means the stored values will differ from your original input values.

‹›

SQL

📋

CREATE TABLE products (
    title TEXT,
    image_vector FLOAT_VECTOR KNN_TYPE='hnsw' KNN_DIMS='4' HNSW_SIMILARITY='l2'
);
INSERT INTO products VALUES 
(1, 'yellow bag', (0.653448,0.192478,0.017971,0.339821)),
(2, 'white bag', (-0.148894,0.748278,0.091892,-0.095406));

If initial ingestion speed matters more than immediate vector search, you can first load the table without an embedding column and add the model-backed float_vector column later.

This approach is useful when you want bulk inserts to finish as quickly as possible and are willing to run embedding generation afterward as a separate, potentially long-running ALTER operation.

How it works:

Create the table with the source text fields and string attributes only
Insert or import all data
Add the embedding column later with ALTER TABLE ... ADD COLUMN

When you add a float_vector column with MODEL_NAME and FROM, Manticore generates embeddings for existing rows during the ALTER. If you later need to regenerate them, use ALTER TABLE ... REBUILD EMBEDDINGS column_name.

Be careful with REBUILD EMBEDDINGS: it regenerates the target column for every row. This includes rows where the current vector was inserted manually and rows where () was used to store a zero vector. After the data is committed, Manticore does not retain whether a stored vector was generated automatically, provided by the user, or created from (), and REBUILD EMBEDDINGS does not treat zero vectors as a special "skip this row" marker.

Limitations:

This method works only for local RT tables. It is not available for tables that are part of a replication cluster, because clustered tables do not support ALTER.

CREATE TABLE products (
    title TEXT,
    description TEXT
);
INSERT INTO products (id, title, description) VALUES
(1, 'smartphone', 'latest mobile device with camera'),
(2, 'laptop computer', 'portable workstation for developers');
ALTER TABLE products
ADD COLUMN embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
MODEL_NAME='Xenova/all-MiniLM-L6-v2' FROM='title,description';

For more details, see Updating table schema.

You can also create float_vector attributes without KNN configuration. In this mode, the vectors are stored but cannot be used for vector search operations.

What you can do:

Store vector data
UPDATE float_vector values (unlike with KNN where you must use REPLACE)

What you cannot do:

Perform KNN searches or vector similarity searches
Use vectors for any search operations
Filter by float_vector values

Temporary storage of vector data before configuring KNN
Staging data that will later be used with KNN
Storing vectors that don't need search capabilities

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, image_vector float_vector);

POST /cli -d "CREATE TABLE products(title text, image_vector float_vector)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'image_vector'=>['type'=>'float_vector']
]);

utilsApi.sql('CREATE TABLE products(title text, image_vector float_vector)')

await utilsApi.sql('CREATE TABLE products(title text, image_vector float_vector)')

res = await utilsApi.sql('CREATE TABLE products(title text, image_vector float_vector)');

utilsApi.sql("CREATE TABLE products(title text, image_vector float_vector)");

utilsApi.Sql("CREATE TABLE products(title text, image_vector float_vector)");

utils_api.sql("CREATE TABLE products(title text, image_vector float_vector)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_float_vector = image_vector
}

A float_vector_array attribute stores several vectors per document rather than a single one. A value is written as an array of vectors, and every document carries its own number of them:

[[0.1, 0.2, 0.3, 0.4], [0.5, 0.6, 0.7, 0.8]]

This suits documents that do not reduce cleanly to one embedding - a long article split into chunks, a product photographed from several angles, a video sampled at keyframes. Instead of storing one row per chunk and deduplicating results afterwards, you keep all of a document's vectors on the document itself.

When the attribute is configured for KNN, all vectors of all documents are indexed together and a document matches if any of its vectors is close to the query. See Multiple vectors per document for the search semantics.

A value is always an array of vectors: [[1,2],[3,4]]. A flat list such as (1,2,3,4) is rejected, because there would be no way to tell one 4-dimensional vector from two 2-dimensional ones.
[] means "no vectors". It is a valid stored value, and it is what an omitted attribute defaults to.
All vectors within one value must have the same number of entries.
An empty inner vector ([[]]) cannot be represented and is rejected. Use [] for "none".
Values are returned in the same nested form they were inserted in.

Currently only supported in real-time tables (not in plain tables)
Not supported in functions or expressions
Cannot be used in regular filters or sorting
Auto embeddings work: a multi-vector chunking strategy (fixed, recursive, sentence) fills the array with one vector per chunk, while a single-vector strategy (truncate, mean) stores a 1-element array - see Chunking strategies. Adding a model-backed float_vector_array with ALTER TABLE ... ADD COLUMN, and ALTER TABLE ... REBUILD EMBEDDINGS on one, are not supported yet; declare the column when creating the table.
Not compatible with the Auto schema mechanism

The parameters are the same ones float_vector takes: KNN_TYPE, KNN_DIMS, HNSW_SIMILARITY, plus the optional HNSW_M, HNSW_EF_CONSTRUCTION and quantization, with two differences:

KNN_DIMS is required, and every vector in every row must have exactly that many entries. A row whose vectors are a different width is rejected on insert.
MODEL_NAME and FROM are accepted, together with a multi-vector CHUNK_STRATEGY that fills the array automatically. See Chunking strategies.

What you can do:

Run KNN searches that match a document on its closest vector
Store a different number of vectors per document, including none at all

What you cannot do:

UPDATE the attribute: use REPLACE, exactly as with a KNN-indexed float_vector
Use the values in regular filters or sorting

A document whose value is [], or whose attribute was omitted, is never returned by a KNN search as it is not close to anything.

Without KNN configuration the vectors are stored but not searchable, and the column needs no options at all. In this mode each value is fully self-describing, so different rows may hold vectors of different widths:

CREATE TABLE products(title text, chunk_vectors float_vector_array);
INSERT INTO products VALUES (1, 'a', [[1,2]]), (2, 'b', [[1,2,3],[4,5,6]]);

UPDATE works in this mode, as it does for a non-KNN float_vector, and [] clears the value.

Creating a KNN-indexed float vector array, filling it, and searching it:

‹›

SQL
JSON

📋

CREATE TABLE articles(title text, chunk_vectors float_vector_array knn_type='hnsw' knn_dims='4' hnsw_similarity='l2');
INSERT INTO articles VALUES
  (1, 'first',  [[1,0,0,0],[0,1,0,0]]),
  (2, 'second', [[0,0,1,0]]),
  (3, 'no vectors yet', []);
SELECT id, knn_dist() FROM articles WHERE knn(chunk_vectors, 5, (1,0,0,0));

Multi-value attributes allow storing variable-length lists of 32-bit unsigned integers. This can be useful for storing one-to-many numeric values, such as tags, product categories, and properties.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, product_codes multi);

CREATE TABLE products(title text, product_codes mva);

POST /cli -d "CREATE TABLE products(title text, product_codes multi)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'product_codes'=>['type'=>'multi']
]);

utilsApi.sql('CREATE TABLE products(title text, product_codes multi)')

await utilsApi.sql('CREATE TABLE products(title text, product_codes multi)')

res = await utilsApi.sql('CREATE TABLE products(title text, product_codes multi)');

utilsApi.sql("CREATE TABLE products(title text, product_codes multi)");

utilsApi.Sql("CREATE TABLE products(title text, product_codes multi)");

utils_api.sql("CREATE TABLE products(title text, product_codes multi)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_multi = product_codes
}

It supports filtering and aggregation, but not sorting. Filtering can be done using a condition that requires at least one element to pass (using ANY()) or all elements (ALL()) to pass.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from products where any(product_codes)=3

POST /search
{
  "table": "products",
  "query":
  {
    "match_all": {},
    "equals" : { "any(product_codes)": 3 }
  }
}

$table->setName('products')->search('')->filter('any(product_codes)','equals',3)->get();

searchApi.search({"table":"products","query":{"match_all":{},"equals":{"any(product_codes)":3}}}})

await searchApi.search({"table":"products","query":{"match_all":{},"equals":{"any(product_codes)":3}}}})

res = await searchApi.search({"table":"products","query":{"match_all":{},"equals":{"any(product_codes)":3}}}})'

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
query.put("equals",new HashMap<String,Integer>(){{
     put("any(product_codes)",3);
}});
searchRequest.setQuery(query);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.AttrFilter = new EqualsFilter("any(product_codes)", 3);
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Information like least or greatest element and length of the list can be extracted. An example shows ordering by the least element of a multi-value attribute.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select least(product_codes) l from products order by l asc

POST /search
{
  "table": "products",
  "query":
  {
    "match_all": {},
    "sort": [ { "product_codes":{ "order":"asc", "mode":"min" } } ]
  }
}

$table->setName('products')->search('')->sort('product_codes','asc','min')->get();

searchApi.search({"table":"products","query":{"match_all":{},"sort":[{"product_codes":{"order":"asc","mode":"min"}}]}})

await searchApi.search({"table":"products","query":{"match_all":{},"sort":[{"product_codes":{"order":"asc","mode":"min"}}]}})

res = await searchApi.search({"table":"products","query":{"match_all":{},"sort":[{"product_codes":{"order":"asc","mode":"min"}}]}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
searchRequest.setSort(new ArrayList<Object>(){{
    add(new HashMap<String,String>(){{ put("product_codes",new HashMap<String,String>(){{ put("order","asc");put("mode","min");}});}});
}});
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Sort = new List<Object> {
    new SortMVA("product_codes", SortOrder.OrderEnum.Asc, SortMVA.ModeEnum.Min)
};
searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut sort_opts = HashMap::new();
sort_opts.insert("order".to_string(), serde_json::json!("asc"));
sort_opts.insert("mode".to_string(), serde_json::json!("min"));
sort_expr.insert("product_codes".to_string(), serde_json::json!(sort_opts));
let sort: [HashMap; 1] = [sort_expr];
let search_req = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    sort: serde_json::json!(sort),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

When grouping by a multi-value attribute, a document will contribute to as many groups as there are different values associated with that document. For instance, if a collection contains exactly one document having a 'product_codes' multi-value attribute with values 5, 7, and 11, grouping on 'product_codes' will produce 3 groups with COUNT(*)equal to 1 and GROUPBY() key values of 5, 7, and 11, respectively. Also, note that grouping by multi-value attributes may lead to duplicate documents in the result set because each document can participate in many groups.

‹›

SQL

📋

insert into products values ( 1, 'doc one', (5,7,11) );
select id, count(*), groupby() from products group by product_codes;

‹›

Response

Query OK, 1 row affected (0.00 sec)
+------+----------+-----------+
| id   | count(*) | groupby() |
+------+----------+-----------+
|    1 |        1 |        11 |
|    1 |        1 |         7 |
|    1 |        1 |         5 |
+------+----------+-----------+
3 rows in set (0.00 sec)

The order of the numbers inserted as values of multivalued attributes is not preserved. Values are stored internally as a sorted set.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

insert into product values (1,'first',(4,2,1,3));
select * from products;

POST /insert
{
    "table":"products",
    "id":1,
    "doc":
    {
        "title":"first",
        "product_codes":[4,2,1,3]
    }
}
POST /search
{
  "table": "products",
  "query": { "match_all": {} }
}

$table->addDocument([
    "title"=>"first",
    "product_codes"=>[4,2,1,3]
]);
$table->search('')-get();

indexApi.insert({"table":"products","id":1,"doc":{"title":"first","product_codes":[4,2,1,3]}})
searchApi.search({"table":"products","query":{"match_all":{}}})

await indexApi.insert({"table":"products","id":1,"doc":{"title":"first","product_codes":[4,2,1,3]}})
await searchApi.search({"table":"products","query":{"match_all":{}}})

await indexApi.insert({"table":"products","id":1,"doc":{"title":"first","product_codes":[4,2,1,3]}});
res = await searchApi.search({"table":"products","query":{"match_all":{}}});

InsertDocumentRequest newdoc = new InsertDocumentRequest();
HashMap<String,Object> doc = new HashMap<String,Object>(){{
    put("title","first");
    put("product_codes",new int[] {4,2,1,3});
}};
newdoc.table("products").id(1L).setDoc(doc);
sqlresult = indexApi.insert(newdoc);
Map<String,Object> query = new HashMap<String,Object>();
query.put("match_all",null);
SearchRequest searchRequest = new SearchRequest();
searchRequest.setTable("products");
searchRequest.setQuery(query);
SearchResponse searchResponse = searchApi.search(searchRequest);
System.out.println(searchResponse.toString() );

Dictionary<string, Object> doc = new Dictionary<string, Object>();
doc.Add("title", "first");
doc.Add("product_codes", new List<Object> {4,2,1,3});
InsertDocumentRequest newdoc = new InsertDocumentRequest(table: "products", id: 1, doc: doc);
var sqlresult = indexApi.Insert(newdoc);
object query =  new { match_all=null };
var searchRequest = new SearchRequest("products", query);
var searchResponse = searchApi.Search(searchRequest);
Console.WriteLine(searchResponse.ToString())

let mut doc = HashMap::new();
doc.insert("title".to_string(), serde_json::json!("first"));
doc.insert("product_codes".to_string(), serde_json::json!([4,2,1,3]));
let insert_req = InsertDocumentRequest::new("products".to_string(), serde_json::json!(doc));
let insert_res = index_api.insert(insert_req).await;
let query = SearchQuery::new();
let search_req = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;
println!("{:?}", search_res);

‹›

Response

Query OK, 1 row affected (0.00 sec)
+------+---------------+-------+
| id   | product_codes | title |
+------+---------------+-------+
|    1 | 1,2,3,4       | first |
+------+---------------+-------+
1 row in set (0.01 sec)

{
   "table":"products",
   "id":1,
   "created":true,
   "result":"created",
   "status":201
}
{
   "took":0,
   "timed_out":false,
   "hits":{
      "total":1,
      "hits":[
         {
            "_id": 1,
            "_score":1,
            "_source":{
               "product_codes":[
                  1,
                  2,
                  3,
                  4
               ],
               "title":"first"
            }
         }
      ]
   }
}

Array
(
    [_index] => products
    [_id] => 1
    [created] => 1
    [result] => created
    [status] => 201
)
Array
(
    [took] => 0
    [timed_out] =>
    [hits] => Array
        (
            [total] => 1
            [hits] => Array
                (
                    [0] => Array
                        (
                            [_id] => 1
                            [_score] => 1
                            [_source] => Array
                                (
                                    [product_codes] => Array
                                        (
                                            [0] => 1
                                            [1] => 2
                                            [2] => 3
                                            [3] => 4
                                        )
                                    [title] => first
                                )
                        )
                )
        )
)

{'created': True,
 'found': None,
 'id': 1,
 'table': 'products',
 'result': 'created'}
{'hits': {'hits': [{u'_id': u'1',
                    u'_score': 1,
                    u'_source': {u'product_codes': [1, 2, 3, 4],
                                 u'title': u'first'}}],
          'total': 1},
 'profile': None,
 'timed_out': False,
 'took': 29}

{'created': True,
 'found': None,
 'id': 1,
 'table': 'products',
 'result': 'created'}
{'hits': {'hits': [{u'_id': u'1',
                    u'_score': 1,
                    u'_source': {u'product_codes': [1, 2, 3, 4],
                                 u'title': u'first'}}],
          'total': 1},
 'profile': None,
 'timed_out': False,
 'took': 29}

{"took":0,"timed_out":false,"hits":{"total":1,"hits":[{"_id": 1,"_score":1,"_source":{"product_codes":[1,2,3,4],"title":"first"}}]}}

class SearchResponse {
    took: 0
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        hits: [{_id=1, _score=1, _source={product_codes=[1, 2, 3, 4], title=first}}]
        aggregations: null
    }
    profile: null
}

class SearchResponse {
    took: 0
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        hits: [{_id=1, _score=1, _source={product_codes=[1, 2, 3, 4], title=first}}]
        aggregations: null
    }
    profile: null
}

class SearchResponse {
    took: 0
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        hits: [{_id=1, _score=1, _source={product_codes=[1, 2, 3, 4], title=first}}]
        aggregations: null
    }
    profile: null
}

A data type that allows storing variable-length lists of 64-bit signed integers. It has the same functionality as multi-value integer.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, values multi64);

CREATE TABLE products(title text, values mva64);

POST /cli -d "CREATE TABLE products(title text, values multi64)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'values'=>['type'=>'multi64']
]);

utilsApi.sql('CREATE TABLE products(title text, values multi64))')

await utilsApi.sql('CREATE TABLE products(title text, values multi64))')

res = await utilsApi.sql('CREATE TABLE products(title text, values multi64))');

utilsApi.sql("CREATE TABLE products(title text, values multi64))");

utilsApi.Sql("CREATE TABLE products(title text, values multi64))");

utils_api.sql("CREATE TABLE products(title text, values multi64))", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_multi_64 = values
}

When you use the columnar storage you can specify the following properties for the attributes.

By default, Manticore Columnar storage stores all attributes in a columnar fashion, as well as in a special docstore row by row. This enables fast execution of queries like SELECT * FROM ..., especially when fetching a large number of records at once. However, if you are sure that you do not need it or wish to save disk space, you can disable it by specifying fast_fetch='0' when creating a table or (if you are defining a table in a config) by using columnar_no_fast_fetch as shown in the following example.

‹›

RT mode
Plain mode

📋

create table t(a int, b int fast_fetch='0') engine='columnar'; desc t;

‹›

Response

+-------+--------+---------------------+
| Field | Type   | Properties          |
+-------+--------+---------------------+
| id    | bigint | columnar fast_fetch |
| a     | uint   | columnar fast_fetch |
| b     | uint   | columnar            |
+-------+--------+---------------------+
3 rows in set (0.00 sec)

Last modified: September 06, 2026

Manticore's data types can be split into two categories: full-text fields and attributes.

Other user-defined SQL object names, including function, plugin, and replication cluster names, follow the same safe UTF-8 rules.

For example:

Valid unquoted names: title, product_id, user_name_2, товары2026, 商品表, 📦метка
Valid quoted names: `2026_архив`, `select`
Valid SQL compatibility column names: @timestamp, @version
Invalid names: 2title without backticks, -price, user@name, user-name, @user_field, and badname containing a zero-width space

Full-text fields:

can be indexed with natural language processing algorithms, therefore can be searched for keywords
cannot be used for sorting or grouping
original document's content can be retrieved
original document's content can be used for highlighting

Full-text fields are represented by the data type text. All other data types are called "attributes".

Attributes are non-full-text values associated with each document that can be used to perform non-full-text filtering, sorting and grouping during a search.

The attributes, unlike full-text fields, are not full-text indexed. They are stored in the table, but it is not possible to search them as full-text.

‹›

SQL
JSON
PHP
Python
Python-asyncio
Javascript
Java
C#
Rust
config

📋

CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp);

POST /cli -d "CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)"

$table = new \Manticoresearch\Table($client);
$table->setName('forum');
$table->create([
    'title'=>['type'=>'text'],
    'content'=>['type'=>'text'],
    'author_id'=>['type'=>'int'],
    'forum_id'=>['type'=>'int'],
    'post_date'=>['type'=>'timestamp']
]);

utilsApi.sql('CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)')

await utilsApi.sql('CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)')

res = await utilsApi.sql('CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)');

utilsApi.sql("CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)");

utilsApi.Sql("CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)");

utils_api.sql("CREATE TABLE forum(title text, content text, author_id int, forum_id int, post_date timestamp)", Some(true)).await;

table forum
{
    type = rt
    path = forum
    # when configuring fields via config, they are indexed (and not stored) by default
    rt_field = title
    rt_field = content
    # this option needs to be specified for the field to be stored
    stored_fields = title, content
    rt_attr_uint = author_id
    rt_attr_uint = forum_id
    rt_attr_timestamp = post_date
}

This example shows running a full-text query filtered by author_id, forum_id and sorted by post_date.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from forum where author_id=123 and forum_id in (1,3,7) order by post_date desc

POST /search
{
  "table": "forum",
  "query":
  {
    "match_all": {},
    "bool":
    {
      "must":
      [
        { "equals": { "author_id": 123 } },
        { "in": { "forum_id": [1,3,7] } }
      ]
    }
  },
  "sort": [ { "post_date": "desc" } ]
}

$client->search([
        'table' => 'forum',
        'query' =>
        [
            'match_all' => [],
            'bool' => [
                'must' => [
                    'equals' => ['author_id' => 123],
                    'in' => [
                        'forum_id' => [
                            1,3,7
                        ]
                    ]
                ]
            ]
        ],
        'sort' => [
        ['post_date' => 'desc']
    ]
]);

searchApi.search({"table":"forum","query":{"match_all":{},"bool":{"must":[{"equals":{"author_id":123}},{"in":{"forum_id":[1,3,7]}}]}},"sort":[{"post_date":"desc"}]})

await searchApi.search({"table":"forum","query":{"match_all":{},"bool":{"must":[{"equals":{"author_id":123}},{"in":{"forum_id":[1,3,7]}}]}},"sort":[{"post_date":"desc"}]})

res = await searchApi.search({"table":"forum","query":{"match_all":{},"bool":{"must":[{"equals":{"author_id":123}},{"in":{"forum_id":[1,3,7]}}]}},"sort":[{"post_date":"desc"}]});

HashMap<String,Object> filters = new HashMap<String,Object>(){{
    put("must", new HashMap<String,Object>(){{
        put("equals",new HashMap<String,Integer>(){{
            put("author_id",123);
        }});
        put("in",
            new HashMap<String,Object>(){{
                put("forum_id",new int[] {1,3,7});
        }});
    }});
}};
Map<String,Object> query = new HashMap<String,Object>();
query.put("match_all",null);
query.put("bool",filters);
SearchRequest searchRequest = new SearchRequest();
searchRequest.setTable("forum");
searchRequest.setQuery(query);
searchRequest.setSort(new ArrayList<Object>(){{
    add(new HashMap<String,String>(){{ put("post_date","desc");}});
}});
SearchResponse searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
var boolFilter = new BoolFilter();
boolFilter.Must = new List<Object> {
    new EqualsFilter("author_id", 123),
    new InFilter("forum_id", new List<Object> {1,3,7})
};
searchRequest.AttrFilter = boolFilter;
searchRequest.Sort = new List<Object> { new SortOrder("post_date", SortOrder.OrderEnum.Desc) };
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut sort = HashMap::new();
sort.insert("post_date".to_string(), serde_json::json!("desc"));
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    sort: serde_json::json!(sort)
    ..Default::default()
};
let search_res = search_api.search(search_req).await;

Manticore supports two types of attribute storages:

row-wise - traditional storage available in Manticore Search out of the box
columnar - provided by Manticore Columnar Library

As can be understood from their names, they store data differently. The traditional row-wise storage:

stores attributes uncompressed
all attributes of the same document are stored in one row close to each other
rows are stored one by one
accessing attributes is basically done by just multiplying the row ID by the stride (length of a single vector) and getting the requested attribute from the calculated memory location. It gives very low random access latency.
attributes have to be in memory to get acceptable performance, otherwise due to the row-wise nature of the storage Manticore may have to read from disk too much unneeded data which is in many cases suboptimal.

With the columnar storage:

each attribute is stored independently of all other attributes in its separate "column"
storage is split into blocks of 65536 entries
the blocks are stored compressed. This often allows storing just a few distinct values instead of storing all of them like in the row-wise storage. High compression ratio allows reading from disk faster and makes the memory requirement much lower
when data is indexed, storage scheme is selected for each block independently. For example, if all values in a block are the same, it gets "const" storage and only one value is stored for the whole block. If there are less than 256 unique values per block, it gets "table" storage and stores indexes to a table of values instead of the values themselves
search in a block can be early rejected if it's clear the requested value is not present in the block.

The columnar storage was designed to handle large data volume that does not fit into RAM, so the recommendations are:

if you have enough memory for all your attributes you will benefit from the row-wise storage
otherwise, the columnar storage can still give you decent performance with a much lower memory footprint which will allow you to store much more documents in your table

The traditional row-wise storage is the default, so if you want everything to be stored in a row-wise fashion, you don't need to do anything when you create a table.

To enable the columnar storage you need to:

specify engine='columnar' in CREATE TABLE to make all attributes of the table columnar. Then, if you want to keep a specific attribute row-wise, you need to add engine='rowwise' when you declare it. For example:
```
create table tbl(title text, type int, price float engine='rowwise') engine='columnar'
```

specify engine='columnar' for a specific attribute in CREATE TABLE to make it columnar. For example:

create table tbl(title text, type int, price float engine='columnar');

create table tbl(title text, type int, price float engine='columnar') engine='rowwise';

in the plain mode you need to list attributes you want to be columnar in columnar_attrs.

Below is the list of data types supported by Manticore Search:

mysql> CREATE TABLE tbl(id bigint, content text);
DESC tbl;
+---------+--------+----------------+
| Field   | Type   | Properties     |
+---------+--------+----------------+
| id      | bigint |                |
| content | text   | indexed stored |
+---------+--------+----------------+
2 rows in set (0.00 sec)

You can also omit specifying ID at all, it will be enabled automatically.

mysql> CREATE TABLE tbl(content text);
DESC tbl;
+---------+--------+----------------+
| Field   | Type   | Properties     |
+---------+--------+----------------+
| id      | bigint |                |
| content | text   | indexed stored |
+---------+--------+----------------+
2 rows in set (0.00 sec)

When working with numeric document IDs, it's important to know that unsigned 64-bit values are handled differently depending on the interface:

MySQL/SQL interface:

IDs greater than 2^63-1 will appear as negative numbers.
When filtering by such large IDs, you must use their signed representation.
This signed representation is only for displaying or filtering existing large IDs; negative IDs are not accepted when inserting or indexing documents.
Use the UINT64() function to view the actual unsigned value.

JSON/HTTP interface:

IDs are always displayed as their original unsigned values, regardless of size.
Both signed and unsigned representations can be used for filtering existing large IDs.
Insert operations accept the full unsigned 64-bit range, but negative id values are rejected.

For example, let's create a table and insert some values around 2^63:

mysql> create table t(id_text string);
Query OK, 0 rows affected (0.01 sec)
mysql> insert into t values(9223372036854775807, '2 ^ 63 - 1'),(9223372036854775808, '2 ^ 63');
Query OK, 2 rows affected (0.00 sec)

Some IDs appear as negative numbers in the results because they exceed 2^63-1. However, using UINT64(id) can reveal their actual unsigned values:

mysql> select *, uint64(id) from t;
+----------------------+------------+---------------------+
| id                   | id_text    | uint64(id)          |
+----------------------+------------+---------------------+
|  9223372036854775807 | 2 ^ 63 - 1 | 9223372036854775807 |
| -9223372036854775808 | 2 ^ 63     | 9223372036854775808 |
+----------------------+------------+---------------------+
2 rows in set (0.00 sec)
--- 2 out of 2 results in 0ms ---

For querying documents with IDs less than 2^63, you can use the unsigned value directly:

mysql> select * from t where id = 9223372036854775807;
+---------------------+------------+
| id                  | id_text    |
+---------------------+------------+
| 9223372036854775807 | 2 ^ 63 - 1 |
+---------------------+------------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

However, for IDs starting from 2^63, you need to use the signed value:

mysql> select * from t where id = -9223372036854775808;
+----------------------+---------+
| id                   | id_text |
+----------------------+---------+
| -9223372036854775808 | 2 ^ 63  |
+----------------------+---------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

If you use an unsigned value instead, you will get an error:

mysql> select * from t where id = 9223372036854775808;
ERROR 1064 (42000): number 9223372036854775808 is out of range [-9223372036854775808..9223372036854775807]

Values that do not fit within 64 bits will trigger a similar error:

mysql> select * from t where id = -9223372036854775809;
ERROR 1064 (42000): number -9223372036854775809 is out of range [-9223372036854775808..9223372036854775807]

The behavior differences between MySQL/SQL and JSON/HTTP interfaces become more apparent with very large document IDs. Here's a comprehensive example:

MySQL/SQL interface:

mysql> drop table if exists t; create table t; insert into t values(17581446260360033510);
Query OK, 0 rows affected (0.01 sec)
mysql> select * from t;
+---------------------+
| id                  |
+---------------------+
| -865297813349518106 |
+---------------------+
mysql> select *, uint64(id) from t;
+---------------------+----------------------+
| id                  | uint64(id)           |
+---------------------+----------------------+
| -865297813349518106 | 17581446260360033510 |
+---------------------+----------------------+
mysql> select * from t where id = -865297813349518106;
+---------------------+
| id                  |
+---------------------+
| -865297813349518106 |
+---------------------+
mysql> select * from t where id = 17581446260360033510;
ERROR 1064 (42000): number 17581446260360033510 is out of range [-9223372036854775808..9223372036854775807]

JSON/HTTP interface:

# Search returns the original unsigned value
curl -s 0:9308/search -d '{"table": "t"}'
{
  "took": 0,
  "timed_out": false,
  "hits": {
    "total": 1,
    "total_relation": "eq",
    "hits": [
      {
        "_id": 17581446260360033510,
        "_score": 1,
        "_source": {}
      }
    ]
  }
}
# Both signed and unsigned values work for filtering the same stored ID
curl -s 0:9308/search -d '{"table": "t", "query": {"equals": {"id": 17581446260360033510}}}'
curl -s 0:9308/search -d '{"table": "t", "query": {"equals": {"id": -865297813349518106}}}'
# Insert with maximum unsigned 64-bit value
curl -s 0:9308/insert -d '{"table": "t", "id": 18446744073709551615, "doc": {}}'

This means when working with large document IDs:

MySQL interface requires using the signed representation for queries but can display the unsigned value with UINT64()
JSON interface consistently uses unsigned values for display and accepts both representations for filtering

SQL returns UUID IDs as strings. For UUID-ID tables, native JSON write responses use key name id, while JSON search and Elasticsearch-compatible responses use _id.

Limitations:

Only the id column can use the uuid type; regular attributes cannot be declared as uuid.
UUID document IDs are supported only for real-time tables, including columnar and replicated real-time tables. They are not supported for plain (indexer-created), percolate/PQ, or shard tables.
ALTER TABLE cannot convert an existing table to or from id uuid.
Range filters (<, <=, >, >=) and numeric or arithmetic expressions on UUID id are not supported.
Unlike numeric-ID tables, UUID-ID tables do not treat 0 as an auto-ID marker.

‹›

SQL

📋

CREATE TABLE products_uuid(id uuid, title text, price int);
INSERT INTO products_uuid(id, title, price) VALUES('550e8400-e29b-41d4-a716-446655440000', 'Crossbody Bag', 19);
INSERT INTO products_uuid(title, price) VALUES('Generated UUID Bag', 29);
SELECT id, price FROM products_uuid WHERE id='550e8400-e29b-41d4-a716-446655440000';

‹›

Response

Query OK, 0 rows affected (0.00 sec)
Query OK, 1 rows affected (0.00 sec)
Query OK, 1 rows affected (0.00 sec)
+--------------------------------------+-------+
| id                                   | price |
+--------------------------------------+-------+
| 550e8400-e29b-41d4-a716-446655440000 |    19 |
+--------------------------------------+-------+
1 row in set (0.00 sec)

General syntax:

string|text [stored|attribute] [indexed]

Properties:

indexed - full-text indexed (can be used in full-text queries)
stored - stored in a docstore (stored on disk, not in RAM, lazy read)
attribute - makes it a string attribute (can sort/group by it)

Specifying at least one property overrides all the default ones (see below), i.e., if you decide to use a custom combination of properties, you need to list all the properties you want.

No properties specified:

string and text are aliases, but if you don't specify any properties, they by default mean different things:

just string by default means attribute (see details below).
just text by default means stored + indexed (see details below).

The text (just text or text/string indexed) data type forms the full-text part of the table. Text fields are indexed and can be searched for keywords.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text);

POST /cli -d "CREATE TABLE products(title text)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text']
]);

utilsApi.sql('CREATE TABLE products(title text)')

await utilsApi.sql('CREATE TABLE products(title text)')

res = await utilsApi.sql('CREATE TABLE products(title text)');

utilsApi.sql("CREATE TABLE products(title text)");

utilsApi.Sql("CREATE TABLE products(title text)");

utils_api.sql("CREATE TABLE products(title text)", Some(true)).await;

table products
{
    type = rt
    path = products
    # when configuring fields via config, they are indexed (and not stored) by default
    rt_field = title
    # this option needs to be specified for the field to be stored
    stored_fields = title
}

This behavior can be overridden by explicitly specifying that the text is only indexed.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text indexed);

POST /cli -d "CREATE TABLE products(title text indexed)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text','options'=>['indexed']]
]);

utilsApi.sql('CREATE TABLE products(title text indexed)')

await utilsApi.sql('CREATE TABLE products(title text indexed)')

res = await utilsApi.sql('CREATE TABLE products(title text indexed)');

utilsApi.sql("CREATE TABLE products(title text indexed)");

utilsApi.Sql("CREATE TABLE products(title text indexed)");

utils_api.sql("CREATE TABLE products(title text indexed)", Some(true)).await;

table products
{
    type = rt
    path = products
    # when configuring fields via config, they are indexed (and not stored) by default
    rt_field = title
}

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from products where match('@title first');

POST /search
{
    "table": "products",
    "query":
    {
        "match": { "title": "first" }
    }
}

$table->setName('products')->search('@title')->get();

searchApi.search({"table":"products","query":{"match":{"title":"first"}}})

await searchApi.search({"table":"products","query":{"match":{"title":"first"}}})

res = await searchApi.search({"table":"products","query":{"match":{"title":"first"}}});

utilsApi.sql("CREATE TABLE products(title text indexed)");

utilsApi.Sql("CREATE TABLE products(title text indexed)");

utils_api.sql("CREATE TABLE products(title text indexed)", Some(true)).await;

If you want to also index the string attribute, you can specify both as string attribute indexed. It will allow full-text searching and works as an attribute.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, keys string);

POST /cli -d "CREATE TABLE products(title text, keys string)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'keys'=>['type'=>'string']
]);

utilsApi.sql('CREATE TABLE products(title text, keys string)')

await utilsApi.sql('CREATE TABLE products(title text, keys string)')

res = await utilsApi.sql('CREATE TABLE products(title text, keys string)');

utilsApi.sql("CREATE TABLE products(title text, keys string)");

utilsApi.Sql("CREATE TABLE products(title text, keys string)");

utils_api.sql("CREATE TABLE products(title text, keys string)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_string = keys
}

Here is an example where we encode the ls command using base64, store it in Manticore, and then decode it to verify that the MD5 checksum remains unchanged:

‹›

Example

Example

📋

# md5sum /bin/ls
43d1b8a7ccda411118e2caba685f4329  /bin/ls
# encoded_data=`base64 -i /bin/ls `
# mysql -P9306 -h0 -e "drop table if exists test; create table test(data text stored); insert into test(data) values('$encoded_data')"
# mysql -P9306 -h0 -NB -e "select data from test" | base64 -d > /tmp/ls | md5sum
43d1b8a7ccda411118e2caba685f4329  -

Integer type allows storing 32 bit unsigned integer values.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, price int);

POST /cli -d "CREATE TABLE products(title text, price int)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'int']
]);

utilsApi.sql('CREATE TABLE products(title text, price int)')

await utilsApi.sql('CREATE TABLE products(title text, price int)')

res = await utilsApi.sql('CREATE TABLE products(title text, price int)');

utilsApi.sql("CREATE TABLE products(title text, price int)");

utilsApi.Sql("CREATE TABLE products(title text, price int)");

utils_api.sql("CREATE TABLE products(title text, price int)", Some(true)).await;

table products
{
    type = rt
    path = products

    rt_field = title
    stored_fields = title

    rt_attr_uint = type
}

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, flags bit(3), tags bit(2) );

POST /cli -d "CREATE TABLE products(title text, flags bit(3), tags bit(2))"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'flags'=>['type'=>'bit(3)'],
    'tags'=>['type'=>'bit(2)']
]);

utilsApi.sql('CREATE TABLE products(title text, flags bit(3), tags bit(2) ')

await utilsApi.sql('CREATE TABLE products(title text, flags bit(3), tags bit(2) ')

res = await utilsApi.sql('CREATE TABLE products(title text, flags bit(3), tags bit(2) ');

utilsApi.sql("CREATE TABLE products(title text, flags bit(3), tags bit(2)");

utilsApi.Sql("CREATE TABLE products(title text, flags bit(3), tags bit(2)");

utils_api.sql("CREATE TABLE products(title text, flags bit(3), tags bit(2)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_uint = flags:3
    rt_attr_uint = tags:2
}

Big integers (bigint) are 64-bit wide signed integers.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, price bigint );

POST /cli -d "CREATE TABLE products(title text, price bigint)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'bigint']
]);

utilsApi.sql('CREATE TABLE products(title text, price bigint )')

await utilsApi.sql('CREATE TABLE products(title text, price bigint )')

res = await utilsApi.sql('CREATE TABLE products(title text, price bigint )');

utilsApi.sql("CREATE TABLE products(title text, price bigint )");

utilsApi.Sql("CREATE TABLE products(title text, price bigint )");

utils_api.sql("CREATE TABLE products(title text, price bigint )", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_bigint = type
}

Declares a boolean attribute. It's equivalent to an integer attribute with bit count of 1.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, sold bool );

POST /cli -d "CREATE TABLE products(title text, sold bool)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'sold'=>['type'=>'bool']
]);

utilsApi.sql('CREATE TABLE products(title text, sold bool )')

await utilsApi.sql('CREATE TABLE products(title text, sold bool )')

res = await utilsApi.sql('CREATE TABLE products(title text, sold bool )');

utilsApi.sql("CREATE TABLE products(title text, sold bool )");

utilsApi.Sql("CREATE TABLE products(title text, sold bool )");

utils_api.sql("CREATE TABLE products(title text, sold bool )", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_bool = sold
}

Numbers without delimiters, at least 10 characters long, are converted to timestamps as is.
%Y-%m-%dT%H:%M:%E*S%Z
%Y-%m-%d'T'%H:%M:%S%Z
%Y-%m-%dT%H:%M:%E*S
%Y-%m-%dT%H:%M:%s
%Y-%m-%dT%H:%M
%Y-%m-%dT%H
%Y-%m-%d
%Y-%m
%Y

The meanings of these conversion specifiers are detailed in the strptime manual, except for %E*S, which stands for milliseconds.

Note that auto-conversion of timestamps is not supported in plain tables.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, date timestamp);

POST /cli -d "CREATE TABLE products(title text, date timestamp)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'date'=>['type'=>'timestamp']
]);

utilsApi.sql('CREATE TABLE products(title text, date timestamp)')

await utilsApi.sql('CREATE TABLE products(title text, date timestamp)')

res = await utilsApi.sql('CREATE TABLE products(title text, date timestamp)');

utilsApi.sql("CREATE TABLE products(title text, date timestamp)");

utilsApi.Sql("CREATE TABLE products(title text, date timestamp)");

utils_api.sql("CREATE TABLE products(title text, date timestamp)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_timestamp = date
}

Real numbers are stored as 32-bit IEEE 754 single precision floats.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, coeff float);

POST /cli -d "CREATE TABLE products(title text, coeff float)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'coeff'=>['type'=>'float']
]);

utilsApi.sql('CREATE TABLE products(title text, coeff float)')

await utilsApi.sql('CREATE TABLE products(title text, coeff float)')

res = await utilsApi.sql('CREATE TABLE products(title text, coeff float)');

utilsApi.sql("CREATE TABLE products(title text, coeff float)");

utilsApi.Sql("CREATE TABLE products(title text, coeff float)");

utils_api.sql("CREATE TABLE products(title text, coeff float)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_float = coeff
}

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select abs(a-b)<=0.00001 from products

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "expressions": { "eps": "abs(a-b)" }
}

$table->setName('products')->search('')->expression('eps','abs(a-b)')->get();

searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"eps":"abs(a-b)"}})

await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"eps":"abs(a-b)"}})

res = await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"eps":"abs(a-b)"}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("ebs","abs(a-b)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Expressions = new List<Object>{
    new Dictionary<string, string> { {"ebs", "abs(a-b)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("ebs".to_string(), serde_json::json!("abs(a-b)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select in(ceil(attr*100),200,250,350) from products

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "expressions": { "inc": "in(ceil(attr*100),200,250,350)" }
}

$table->setName('products')->search('')->expression('inc','in(ceil(attr*100),200,250,350)')->get();

searchApi.search({"table":"products","query":{"match_all":{}}},"expressions":{"inc":"in(ceil(attr*100),200,250,350)"}})

await searchApi.search({"table":"products","query":{"match_all":{}}},"expressions":{"inc":"in(ceil(attr*100),200,250,350)"}})

res = await searchApi.search({"table":"products","query":{"match_all":{}}},"expressions":{"inc":"in(ceil(attr*100),200,250,350)"}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("inc","in(ceil(attr*100),200,250,350)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Expressions = new List<Object> {
    new Dictionary<string, string> { {"ebs", "in(ceil(attr*100),200,250,350)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("ebs".to_string(), serde_json::json!("in(ceil(attr*100),200,250,350)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Now, Manticore first outputs a number with 6 digits, then parses and compares it to the original value. If they don't match, additional digits are added until they do.

For example, if a float value was inserted as 19.45, Manticore will display it as 19.450001 to accurately represent the stored value.

‹›

Example

Example

📋

insert into t(id, f) values(1, 19.45)
--------------
Query OK, 1 row affected (0.02 sec)
--------------
select * from t
--------------
+------+-----------+
| id   | f         |
+------+-----------+
|    1 | 19.450001 |
+------+-----------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, data json);

POST /cli -d "CREATE TABLE products(title text, data json)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'data'=>['type'=>'json']
]);

utilsApi.sql('CREATE TABLE products(title text, data json)')

await utilsApi.sql('CREATE TABLE products(title text, data json)')

res = await utilsApi.sql('CREATE TABLE products(title text, data json)');

utilsApi.sql("CREATE TABLE products(title text, data json)");

utilsApi.Sql("CREATE TABLE products(title text, data json)");

utils_api.sql("CREATE TABLE products(title text, data json)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_json = data
}

JSON properties can be used in most operations. There are also special functions such as ALL(), ANY(), GREATEST(), LEAST() and INDEXOF() that allow traversal of property arrays.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select indexof(x>2 for x in data.intarray) from products

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "expressions": { "idx": "indexof(x>2 for x in data.intarray)" }
}

$table->setName('products')->search('')->expression('idx','indexof(x>2 for x in data.intarray)')->get();

searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"idx":"indexof(x>2 for x in data.intarray)"}})

await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"idx":"indexof(x>2 for x in data.intarray)"}})

res = await searchApi.search({"table":"products","query":{"match_all":{}},"expressions":{"idx":"indexof(x>2 for x in data.intarray)"}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("idx","indexof(x>2 for x in data.intarray)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Expressions = new List<Object> {
    new Dictionary<string, string> { {"idx", "indexof(x>2 for x in data.intarray)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("idx".to_string(), serde_json::json!("indexof(x>2 for x in data.intarray)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Text properties are treated the same as strings, so it's not possible to use them in full-text match expressions. However, string functions such as REGEX() can be used.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select regex(data.name, 'est') as c from products where c>0

POST /search
{
  "table": "products",
  "query":
  {
    "match_all": {},
    "range": { "c": { "gt": 0 } } }
  },
  "expressions": { "c": "regex(data.name, 'est')" }
}

$table->setName('products')->search('')->expression('idx',"regex(data.name, 'est')")->filter('c','gt',0)->get();

searchApi.search({"table":"products","query":{"match_all":{},"range":{"c":{"gt":0}}}},"expressions":{"c":"regex(data.name, 'est')"}})

await searchApi.search({"table":"products","query":{"match_all":{},"range":{"c":{"gt":0}}}},"expressions":{"c":"regex(data.name, 'est')"}})

res = await searchApi.search({"table":"products","query":{"match_all":{},"range":{"c":{"gt":0}}}},"expressions":{"c":"regex(data.name, 'est')"}}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
query.put("range", new HashMap<String,Object>(){{
    put("c", new HashMap<String,Object>(){{
        put("gt",0);
    }});
}});
searchRequest.setQuery(query);
Object expressions = new HashMap<String,Object>(){{
    put("idx","indexof(x>2 for x in data.intarray)");
}};
searchRequest.setExpressions(expressions);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
var rangeFilter = new RangeFilter("c");
rangeFilter.Gt = 0;
searchRequest.AttrFilter = rangeFilter;
searchRequest.Expressions = new List<Object> {
    new Dictionary<string, string> { {"idx", "indexof(x>2 for x in data.intarray)"} }
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut expr = HashMap::new();
expr.insert("idx".to_string(), serde_json::json!("indexof(x>2 for x in data.intarray)"));
let expressions: [HashMap; 1] = [expr];
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    expressions: serde_json::json!(expressions),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from products order by double(data.myfloat) desc

POST /search
{
  "table": "products",
  "query": { "match_all": {} } },
  "sort": [ { "double(data.myfloat)": { "order": "desc"} } ]
}

$table->setName('products')->search('')->sort('double(data.myfloat)','desc')->get();

searchApi.search({"table":"products","query":{"match_all":{}}},"sort":[{"double(data.myfloat)":{"order":"desc"}}]})

await searchApi.search({"table":"products","query":{"match_all":{}}},"sort":[{"double(data.myfloat)":{"order":"desc"}}]})

res = await searchApi.search({"table":"products","query":{"match_all":{}}},"sort":[{"double(data.myfloat)":{"order":"desc"}}]});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
searchRequest.setSort(new ArrayList<Object>(){{
    add(new HashMap<String,String>(){{ put("double(data.myfloat)",new HashMap<String,String>(){{ put("order","desc");}});}});
}});
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Sort = new List<Object> {
    new SortOrder("double(data.myfloat)", SortOrder.OrderEnum.Desc)
};
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut sort = HashMap::new();
sort.insert("double(data.myfloat)".to_string(), serde_json::json!("desc"));
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    sort: serde_json::json!(sort)
    ..Default::default()
};
let search_res = search_api.search(search_req).await;

Preserves the exact order of values (unlike MVAs which may reorder)
Retains duplicate values (unlike MVAs which deduplicate)
No additional processing during insertion (unlike MVAs which sort and deduplicate)

Important: The float_vector data type is not compatible with the Auto schema mechanism.

Currently only supported in real-time tables (not in plain tables)
Not supported in other functions or expressions
Cannot be used in regular filters or sorting

What you can do:

Perform KNN (k-nearest neighbor) vector searches to find similar documents
Build semantic search, recommendations, and AI-powered features
Use auto embeddings to automatically generate vectors from text

What you cannot do:

UPDATE float_vector values (you must use REPLACE instead)
Use float vectors in regular filters or sorting
Filter by float_vector values except through vector search operations

When creating a table with float_vector attributes for KNN search, you can specify the following parameters:

Required parameters:

KNN_TYPE: Currently only 'hnsw' is supported
KNN_DIMS: Number of dimensions in the vectors (required for manual vector insertion, omitted when using MODEL_NAME)
HNSW_SIMILARITY: Distance function - 'l2', 'ip' (inner product), or 'cosine'

Optional parameters:

HNSW_M: Maximum connections in the graph (default: 16)
HNSW_EF_CONSTRUCTION: Construction time/accuracy trade-off (default: 200)

Chunking parameters (when using MODEL_NAME, see Chunking strategies):

CHUNK_STRATEGY: how a document becomes vectors: 'truncate' (default), 'mean', 'fixed', 'recursive' or 'sentence'. The last three produce several vectors per document and require a float_vector_array column.
MAX_TOKENS: chunk size in tokens; 0 (default) uses the model's own limit
OVERLAP_TOKENS: tokens shared between consecutive chunks; requires an explicit non-zero MAX_TOKENS; a large overlap is reduced so chunks still advance
MAX_CHUNKS: ceiling on vectors per document; 0 (default) means unlimited

Auto-embeddings parameters (when using MODEL_NAME):

MODEL_NAME: The embedding model to use (e.g., 'Xenova/all-MiniLM-L6-v2' for the fast ONNX path, 'sentence-transformers/all-MiniLM-L6-v2', or 'openai/text-embedding-ada-002')
FROM: Comma-separated list of field names to use for embedding generation, or empty string '' to use all text/string fields
API_KEY: API key for API-based models (OpenAI, Voyage, Jina)

For more details on setting up float vectors and using them in searches, see KNN search.

Simplified workflow: Just insert text, embeddings are generated automatically
No manual vector computation: No need to run separate embedding models
Consistent embeddings: Same model ensures consistent vector representations
Multiple model support: Choose from ONNX models on Hugging Face (recommended — runs on Manticore's fast ONNX Runtime backend), sentence-transformers, Qwen embedding models, OpenAI, Voyage, and Jina models
Flexible field selection: Control which fields are used for embedding generation

When creating a table with auto embeddings, specify these additional parameters:

MODEL_NAME: The embedding model to use for automatic vector generation
FROM: Which fields to use for embedding generation (empty string means all text/string fields)
API_KEY: Required for remote models (OpenAI, Voyage, Jina). The API key is validated during table creation by making a real API request.
API_URL: Optional. Custom API endpoint URL. If not specified, uses the default provider endpoint (e.g., https://api.openai.com/v1/embeddings for OpenAI).
API_TIMEOUT: Optional. HTTP timeout in seconds for API requests. Default is 10 seconds. Set to '0' to use the default timeout. Applies to both validation requests during table creation and embedding generation during INSERT operations.
MAX_INPUT_TOKENS: Optional. Caps the number of tokens taken from each input text before it is embedded; longer texts are truncated. '0' (default) means the model's own context limit. Long-context models such as Qwen/Qwen3-Embedding-0.6B accept up to 32,768 tokens, and embedding time on CPU grows superlinearly with input length (a 5 KB document can take minutes), so set a cap (for example '512') when the text fields may contain long or unbounded content. Applies to local models; the setting can be changed later with ALTER TABLE ... MODIFY COLUMN ... MAX_INPUT_TOKENS='...' without re-embedding existing rows.

Supported embedding models:

ONNX (recommended): Any Hugging Face model that ships an .onnx file — e.g. Xenova/all-MiniLM-L6-v2, Xenova/all-MiniLM-L12-v2, Xenova/bge-small-en-v1.5, Xenova/multilingual-e5-small. No API key needed. Runs on Manticore's fast ONNX Runtime backend (~14× faster than the SentenceTransformers path on the same hardware — see 14× faster embeddings). Both Xenova and onnx-models publish a lot of ONNX-converted models; for embeddings, look for ones tagged with the feature-extraction task.
Sentence Transformers: Any suitable BERT-based Hugging Face model (e.g., sentence-transformers/all-MiniLM-L6-v2) — no API key needed. Still supported; use this if the model you want isn't published as ONNX.
Qwen local embeddings: Qwen embedding models such as Qwen/Qwen3-Embedding-0.6B — no API key needed. Manticore downloads the model when you create the table.
OpenAI, Voyage, Jina: Remote embedding models (e.g., openai/text-embedding-ada-002, openai:text-embedding-ada-002, voyage/voyage-3.5-lite, jina/jina-embeddings-v2-base-en) - require API_KEY='***' parameter. Optionally specify API_URL='<CUSTOM_URL>' to use a custom API endpoint, and API_TIMEOUT='<SECONDS>' to configure HTTP timeout (default is 10 seconds).

‹›

SQL
JSON

📋

Using a local ONNX model — recommended, runs on the fast ONNX path (no API key needed)

CREATE TABLE products (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='Xenova/all-MiniLM-L6-v2' FROM='title'
);

Using a sentence-transformers model (no API key needed; runs on the Candle path — use ONNX above when available)

CREATE TABLE products_st (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='sentence-transformers/all-MiniLM-L6-v2' FROM='title'
);

Using Qwen local embeddings (no API key needed)

CREATE TABLE products_qwen (
    title TEXT,
    description TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='Qwen/Qwen3-Embedding-0.6B' FROM='title'
);

Using OpenAI model (requires API_KEY parameter)

CREATE TABLE products_openai (
    title TEXT,
    content TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine'
    MODEL_NAME='openai/text-embedding-ada-002' FROM='title,content' API_KEY='<OPENAI_API_KEY>'
);

Using OpenAI with custom API URL and timeout (optional)

CREATE TABLE products_openai_custom (
    title TEXT,
    content TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine'
    MODEL_NAME='openai:text-embedding-ada-002' FROM='title,content'
    API_KEY='***' API_URL='https://custom-api.example.com/v1/embeddings' API_TIMEOUT='30'
);

Using OpenRouter with a provider-qualified model ID

CREATE TABLE products_openrouter (
    title TEXT,
    content TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='cosine'
    MODEL_NAME='openai:openai/text-embedding-ada-002' FROM='title,content'
    API_KEY='***' API_URL='https://openrouter.ai/api/v1/embeddings' API_TIMEOUT='30'
);

Using all text fields for embeddings (FROM is empty)

CREATE TABLE products_all_fields (
    title TEXT,
    description TEXT,
    tags TEXT,
    embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
    MODEL_NAME='Xenova/all-MiniLM-L6-v2' FROM=''
);

The FROM parameter controls which fields are used for embedding generation:

Specific fields: FROM='title' - only the title field is used
Multiple fields: FROM='title,description' - both title and description are concatenated and used
All text fields: FROM='' (empty) - all text (full-text field) and string (string attribute) fields in the table are used
Manual override: Even when MODEL_NAME is configured, you can still provide your own vector in INSERT/REPLACE
Empty vectors: You can insert () to skip embedding generation for that row; Manticore stores an all-zero vector with the model's dimension

When using auto embeddings, you have three insert modes:

Omit the vector column and let Manticore generate the embedding from the fields listed in FROM
Provide your own vector explicitly to override auto generation for that row
Provide () to skip generation and store an all-zero vector instead

-- Insert text data - embeddings generated automatically
INSERT INTO products (title, description) VALUES 
('smartphone', 'latest mobile device with camera'),
('laptop computer', 'portable workstation for developers');
-- Insert with a user-provided vector - no auto generation for this row
INSERT INTO products (title, embedding_vector) VALUES
('machine learning artificial intelligence', (0.653448,0.192478,0.017971,0.339821));
-- Insert with empty vector - no auto generation, stores a zero vector
INSERT INTO products (title, description, embedding_vector) VALUES
('no-vector item', 'this item has no embedding', ());

Alternatively, you can manually insert pre-computed vector data. This requires you to compute the vectors yourself using external tools or models, then insert them into Manticore.

‹›

SQL

📋

CREATE TABLE products (
    title TEXT,
    image_vector FLOAT_VECTOR KNN_TYPE='hnsw' KNN_DIMS='4' HNSW_SIMILARITY='l2'
);
INSERT INTO products VALUES 
(1, 'yellow bag', (0.653448,0.192478,0.017971,0.339821)),
(2, 'white bag', (-0.148894,0.748278,0.091892,-0.095406));

If initial ingestion speed matters more than immediate vector search, you can first load the table without an embedding column and add the model-backed float_vector column later.

This approach is useful when you want bulk inserts to finish as quickly as possible and are willing to run embedding generation afterward as a separate, potentially long-running ALTER operation.

How it works:

Create the table with the source text fields and string attributes only
Insert or import all data
Add the embedding column later with ALTER TABLE ... ADD COLUMN

Limitations:

This method works only for local RT tables. It is not available for tables that are part of a replication cluster, because clustered tables do not support ALTER.

CREATE TABLE products (
    title TEXT,
    description TEXT
);
INSERT INTO products (id, title, description) VALUES
(1, 'smartphone', 'latest mobile device with camera'),
(2, 'laptop computer', 'portable workstation for developers');
ALTER TABLE products
ADD COLUMN embedding_vector FLOAT_VECTOR KNN_TYPE='hnsw' HNSW_SIMILARITY='l2'
MODEL_NAME='Xenova/all-MiniLM-L6-v2' FROM='title,description';

For more details, see Updating table schema.

You can also create float_vector attributes without KNN configuration. In this mode, the vectors are stored but cannot be used for vector search operations.

What you can do:

Store vector data
UPDATE float_vector values (unlike with KNN where you must use REPLACE)

What you cannot do:

Perform KNN searches or vector similarity searches
Use vectors for any search operations
Filter by float_vector values

Temporary storage of vector data before configuring KNN
Staging data that will later be used with KNN
Storing vectors that don't need search capabilities

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, image_vector float_vector);

POST /cli -d "CREATE TABLE products(title text, image_vector float_vector)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'image_vector'=>['type'=>'float_vector']
]);

utilsApi.sql('CREATE TABLE products(title text, image_vector float_vector)')

await utilsApi.sql('CREATE TABLE products(title text, image_vector float_vector)')

res = await utilsApi.sql('CREATE TABLE products(title text, image_vector float_vector)');

utilsApi.sql("CREATE TABLE products(title text, image_vector float_vector)");

utilsApi.Sql("CREATE TABLE products(title text, image_vector float_vector)");

utils_api.sql("CREATE TABLE products(title text, image_vector float_vector)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_float_vector = image_vector
}

A float_vector_array attribute stores several vectors per document rather than a single one. A value is written as an array of vectors, and every document carries its own number of them:

[[0.1, 0.2, 0.3, 0.4], [0.5, 0.6, 0.7, 0.8]]

A value is always an array of vectors: [[1,2],[3,4]]. A flat list such as (1,2,3,4) is rejected, because there would be no way to tell one 4-dimensional vector from two 2-dimensional ones.
[] means "no vectors". It is a valid stored value, and it is what an omitted attribute defaults to.
All vectors within one value must have the same number of entries.
An empty inner vector ([[]]) cannot be represented and is rejected. Use [] for "none".
Values are returned in the same nested form they were inserted in.

Currently only supported in real-time tables (not in plain tables)
Not supported in functions or expressions
Cannot be used in regular filters or sorting
Auto embeddings work: a multi-vector chunking strategy (fixed, recursive, sentence) fills the array with one vector per chunk, while a single-vector strategy (truncate, mean) stores a 1-element array - see Chunking strategies. Adding a model-backed float_vector_array with ALTER TABLE ... ADD COLUMN, and ALTER TABLE ... REBUILD EMBEDDINGS on one, are not supported yet; declare the column when creating the table.
Not compatible with the Auto schema mechanism

The parameters are the same ones float_vector takes: KNN_TYPE, KNN_DIMS, HNSW_SIMILARITY, plus the optional HNSW_M, HNSW_EF_CONSTRUCTION and quantization, with two differences:

KNN_DIMS is required, and every vector in every row must have exactly that many entries. A row whose vectors are a different width is rejected on insert.
MODEL_NAME and FROM are accepted, together with a multi-vector CHUNK_STRATEGY that fills the array automatically. See Chunking strategies.

What you can do:

Run KNN searches that match a document on its closest vector
Store a different number of vectors per document, including none at all

What you cannot do:

UPDATE the attribute: use REPLACE, exactly as with a KNN-indexed float_vector
Use the values in regular filters or sorting

A document whose value is [], or whose attribute was omitted, is never returned by a KNN search as it is not close to anything.

CREATE TABLE products(title text, chunk_vectors float_vector_array);
INSERT INTO products VALUES (1, 'a', [[1,2]]), (2, 'b', [[1,2,3],[4,5,6]]);

UPDATE works in this mode, as it does for a non-KNN float_vector, and [] clears the value.

Creating a KNN-indexed float vector array, filling it, and searching it:

‹›

SQL
JSON

📋

CREATE TABLE articles(title text, chunk_vectors float_vector_array knn_type='hnsw' knn_dims='4' hnsw_similarity='l2');
INSERT INTO articles VALUES
  (1, 'first',  [[1,0,0,0],[0,1,0,0]]),
  (2, 'second', [[0,0,1,0]]),
  (3, 'no vectors yet', []);
SELECT id, knn_dist() FROM articles WHERE knn(chunk_vectors, 5, (1,0,0,0));

Multi-value attributes allow storing variable-length lists of 32-bit unsigned integers. This can be useful for storing one-to-many numeric values, such as tags, product categories, and properties.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, product_codes multi);

CREATE TABLE products(title text, product_codes mva);

POST /cli -d "CREATE TABLE products(title text, product_codes multi)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'product_codes'=>['type'=>'multi']
]);

utilsApi.sql('CREATE TABLE products(title text, product_codes multi)')

await utilsApi.sql('CREATE TABLE products(title text, product_codes multi)')

res = await utilsApi.sql('CREATE TABLE products(title text, product_codes multi)');

utilsApi.sql("CREATE TABLE products(title text, product_codes multi)");

utilsApi.Sql("CREATE TABLE products(title text, product_codes multi)");

utils_api.sql("CREATE TABLE products(title text, product_codes multi)", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_multi = product_codes
}

It supports filtering and aggregation, but not sorting. Filtering can be done using a condition that requires at least one element to pass (using ANY()) or all elements (ALL()) to pass.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select * from products where any(product_codes)=3

POST /search
{
  "table": "products",
  "query":
  {
    "match_all": {},
    "equals" : { "any(product_codes)": 3 }
  }
}

$table->setName('products')->search('')->filter('any(product_codes)','equals',3)->get();

searchApi.search({"table":"products","query":{"match_all":{},"equals":{"any(product_codes)":3}}}})

await searchApi.search({"table":"products","query":{"match_all":{},"equals":{"any(product_codes)":3}}}})

res = await searchApi.search({"table":"products","query":{"match_all":{},"equals":{"any(product_codes)":3}}}})'

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
query.put("equals",new HashMap<String,Integer>(){{
     put("any(product_codes)",3);
}});
searchRequest.setQuery(query);
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.AttrFilter = new EqualsFilter("any(product_codes)", 3);
var searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let search_request = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

Information like least or greatest element and length of the list can be extracted. An example shows ordering by the least element of a multi-value attribute.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

select least(product_codes) l from products order by l asc

POST /search
{
  "table": "products",
  "query":
  {
    "match_all": {},
    "sort": [ { "product_codes":{ "order":"asc", "mode":"min" } } ]
  }
}

$table->setName('products')->search('')->sort('product_codes','asc','min')->get();

searchApi.search({"table":"products","query":{"match_all":{},"sort":[{"product_codes":{"order":"asc","mode":"min"}}]}})

await searchApi.search({"table":"products","query":{"match_all":{},"sort":[{"product_codes":{"order":"asc","mode":"min"}}]}})

res = await searchApi.search({"table":"products","query":{"match_all":{},"sort":[{"product_codes":{"order":"asc","mode":"min"}}]}});

searchRequest = new SearchRequest();
searchRequest.setTable("forum");
query = new HashMap<String,Object>();
query.put("match_all",null);
searchRequest.setQuery(query);
searchRequest.setSort(new ArrayList<Object>(){{
    add(new HashMap<String,String>(){{ put("product_codes",new HashMap<String,String>(){{ put("order","asc");put("mode","min");}});}});
}});
searchResponse = searchApi.search(searchRequest);

object query =  new { match_all=null };
var searchRequest = new SearchRequest("forum", query);
searchRequest.Sort = new List<Object> {
    new SortMVA("product_codes", SortOrder.OrderEnum.Asc, SortMVA.ModeEnum.Min)
};
searchResponse = searchApi.Search(searchRequest);

let query = SearchQuery::new();
let mut sort_opts = HashMap::new();
sort_opts.insert("order".to_string(), serde_json::json!("asc"));
sort_opts.insert("mode".to_string(), serde_json::json!("min"));
sort_expr.insert("product_codes".to_string(), serde_json::json!(sort_opts));
let sort: [HashMap; 1] = [sort_expr];
let search_req = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    sort: serde_json::json!(sort),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;

‹›

SQL

📋

insert into products values ( 1, 'doc one', (5,7,11) );
select id, count(*), groupby() from products group by product_codes;

‹›

Response

Query OK, 1 row affected (0.00 sec)
+------+----------+-----------+
| id   | count(*) | groupby() |
+------+----------+-----------+
|    1 |        1 |        11 |
|    1 |        1 |         7 |
|    1 |        1 |         5 |
+------+----------+-----------+
3 rows in set (0.00 sec)

The order of the numbers inserted as values of multivalued attributes is not preserved. Values are stored internally as a sorted set.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust

📋

insert into product values (1,'first',(4,2,1,3));
select * from products;

POST /insert
{
    "table":"products",
    "id":1,
    "doc":
    {
        "title":"first",
        "product_codes":[4,2,1,3]
    }
}
POST /search
{
  "table": "products",
  "query": { "match_all": {} }
}

$table->addDocument([
    "title"=>"first",
    "product_codes"=>[4,2,1,3]
]);
$table->search('')-get();

indexApi.insert({"table":"products","id":1,"doc":{"title":"first","product_codes":[4,2,1,3]}})
searchApi.search({"table":"products","query":{"match_all":{}}})

await indexApi.insert({"table":"products","id":1,"doc":{"title":"first","product_codes":[4,2,1,3]}})
await searchApi.search({"table":"products","query":{"match_all":{}}})

await indexApi.insert({"table":"products","id":1,"doc":{"title":"first","product_codes":[4,2,1,3]}});
res = await searchApi.search({"table":"products","query":{"match_all":{}}});

InsertDocumentRequest newdoc = new InsertDocumentRequest();
HashMap<String,Object> doc = new HashMap<String,Object>(){{
    put("title","first");
    put("product_codes",new int[] {4,2,1,3});
}};
newdoc.table("products").id(1L).setDoc(doc);
sqlresult = indexApi.insert(newdoc);
Map<String,Object> query = new HashMap<String,Object>();
query.put("match_all",null);
SearchRequest searchRequest = new SearchRequest();
searchRequest.setTable("products");
searchRequest.setQuery(query);
SearchResponse searchResponse = searchApi.search(searchRequest);
System.out.println(searchResponse.toString() );

Dictionary<string, Object> doc = new Dictionary<string, Object>();
doc.Add("title", "first");
doc.Add("product_codes", new List<Object> {4,2,1,3});
InsertDocumentRequest newdoc = new InsertDocumentRequest(table: "products", id: 1, doc: doc);
var sqlresult = indexApi.Insert(newdoc);
object query =  new { match_all=null };
var searchRequest = new SearchRequest("products", query);
var searchResponse = searchApi.Search(searchRequest);
Console.WriteLine(searchResponse.ToString())

let mut doc = HashMap::new();
doc.insert("title".to_string(), serde_json::json!("first"));
doc.insert("product_codes".to_string(), serde_json::json!([4,2,1,3]));
let insert_req = InsertDocumentRequest::new("products".to_string(), serde_json::json!(doc));
let insert_res = index_api.insert(insert_req).await;
let query = SearchQuery::new();
let search_req = SearchRequest {
    table: "forum".to_string(),
    query: Some(Box::new(query)),
    ..Default::default(),
};
let search_res = search_api.search(search_req).await;
println!("{:?}", search_res);

‹›

Response

Query OK, 1 row affected (0.00 sec)
+------+---------------+-------+
| id   | product_codes | title |
+------+---------------+-------+
|    1 | 1,2,3,4       | first |
+------+---------------+-------+
1 row in set (0.01 sec)

{
   "table":"products",
   "id":1,
   "created":true,
   "result":"created",
   "status":201
}
{
   "took":0,
   "timed_out":false,
   "hits":{
      "total":1,
      "hits":[
         {
            "_id": 1,
            "_score":1,
            "_source":{
               "product_codes":[
                  1,
                  2,
                  3,
                  4
               ],
               "title":"first"
            }
         }
      ]
   }
}

Array
(
    [_index] => products
    [_id] => 1
    [created] => 1
    [result] => created
    [status] => 201
)
Array
(
    [took] => 0
    [timed_out] =>
    [hits] => Array
        (
            [total] => 1
            [hits] => Array
                (
                    [0] => Array
                        (
                            [_id] => 1
                            [_score] => 1
                            [_source] => Array
                                (
                                    [product_codes] => Array
                                        (
                                            [0] => 1
                                            [1] => 2
                                            [2] => 3
                                            [3] => 4
                                        )
                                    [title] => first
                                )
                        )
                )
        )
)

{'created': True,
 'found': None,
 'id': 1,
 'table': 'products',
 'result': 'created'}
{'hits': {'hits': [{u'_id': u'1',
                    u'_score': 1,
                    u'_source': {u'product_codes': [1, 2, 3, 4],
                                 u'title': u'first'}}],
          'total': 1},
 'profile': None,
 'timed_out': False,
 'took': 29}

{'created': True,
 'found': None,
 'id': 1,
 'table': 'products',
 'result': 'created'}
{'hits': {'hits': [{u'_id': u'1',
                    u'_score': 1,
                    u'_source': {u'product_codes': [1, 2, 3, 4],
                                 u'title': u'first'}}],
          'total': 1},
 'profile': None,
 'timed_out': False,
 'took': 29}

{"took":0,"timed_out":false,"hits":{"total":1,"hits":[{"_id": 1,"_score":1,"_source":{"product_codes":[1,2,3,4],"title":"first"}}]}}

class SearchResponse {
    took: 0
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        hits: [{_id=1, _score=1, _source={product_codes=[1, 2, 3, 4], title=first}}]
        aggregations: null
    }
    profile: null
}

class SearchResponse {
    took: 0
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        hits: [{_id=1, _score=1, _source={product_codes=[1, 2, 3, 4], title=first}}]
        aggregations: null
    }
    profile: null
}

class SearchResponse {
    took: 0
    timedOut: false
    hits: class SearchResponseHits {
        total: 1
        hits: [{_id=1, _score=1, _source={product_codes=[1, 2, 3, 4], title=first}}]
        aggregations: null
    }
    profile: null
}

A data type that allows storing variable-length lists of 64-bit signed integers. It has the same functionality as multi-value integer.

‹›

SQL
JSON
PHP
Python
Python-asyncio
javascript
java
C#
Rust
config

📋

CREATE TABLE products(title text, values multi64);

CREATE TABLE products(title text, values mva64);

POST /cli -d "CREATE TABLE products(title text, values multi64)"

$table = new \Manticoresearch\Table($client);
$table->setName('products');
$table->create([
    'title'=>['type'=>'text'],
    'values'=>['type'=>'multi64']
]);

utilsApi.sql('CREATE TABLE products(title text, values multi64))')

await utilsApi.sql('CREATE TABLE products(title text, values multi64))')

res = await utilsApi.sql('CREATE TABLE products(title text, values multi64))');

utilsApi.sql("CREATE TABLE products(title text, values multi64))");

utilsApi.Sql("CREATE TABLE products(title text, values multi64))");

utils_api.sql("CREATE TABLE products(title text, values multi64))", Some(true)).await;

table products
{
    type = rt
    path = products
    rt_field = title
    stored_fields = title
    rt_attr_multi_64 = values
}

When you use the columnar storage you can specify the following properties for the attributes.

‹›

RT mode
Plain mode

📋

create table t(a int, b int fast_fetch='0') engine='columnar'; desc t;

‹›

Response

+-------+--------+---------------------+
| Field | Type   | Properties          |
+-------+--------+---------------------+
| id    | bigint | columnar fast_fetch |
| a     | uint   | columnar fast_fetch |
| b     | uint   | columnar            |
+-------+--------+---------------------+
3 rows in set (0.00 sec)

Data types Creating a local table

Last modified: September 06, 2026

In Manticore Search, there are two ways to manage tables:

Real-time mode requires no table definition in the configuration file. However, the data_dir directive in the searchd section is mandatory. Table files are stored inside the data_dir.

Replication is only available in this mode.

You can use SQL commands such as CREATE TABLE, ALTER TABLE and DROP TABLE to create and modify table schema, and to drop it. This mode is particularly useful for real-time and percolate tables.

ASCII letters in table names are converted to lowercase when created. Non-ASCII UTF-8 characters retain their original spelling and do not undergo Unicode case folding. See table, field, and attribute name syntax.

In this mode, you can specify the table schema in the configuration file. Manticore reads this schema on startup and creates the table if it doesn't exist yet. This mode is particularly useful for plain tables that use data from an external storage.

To drop a table, remove it from the configuration file or remove the path setting and send a HUP signal to the server or restart it.

Configuration section names are case-sensitive in this mode. Table, field, and attribute names, as well as named source sections, can contain non-ASCII UTF-8 characters. Unicode case folding and Unicode normalization are not applied, so use the exact Unicode spelling consistently. See table, field, and attribute name syntax.

All table types are supported in this mode.

Table type	RT mode	Plain mode
Real-time	supported	supported
Plain	not supported	supported
Percolate	supported	supported
Distributed	supported	supported
Template	not supported	supported

Row-wise and columnar attribute storages Real-time table

Last modified: September 02, 2026

A real-time table is a main type of table in Manticore. It lets you add, update, and delete documents, and you can see these changes right away. You can set up a real-time Table in a configuration file or use commands like CREATE, UPDATE, DELETE, or ALTER.

Internally a real-time table consists of one or more plain tables called chunks. There are two kinds of chunks:

multiple disk chunks - these are saved on a disk and are structured like a plain table.
single ram chunk - this is kept in memory and collects all changes.

The size of the RAM chunk is controlled by the rt_mem_limit setting. Once this limit is reached, the RAM chunk is transferred to disk as a disk chunk. If there are too many disk chunks, Manticore combines some of them to improve performance.

You can create a new real-time table in two ways: by using the CREATE TABLE command or through the _mapping endpoint of the HTTP JSON API.

You can use this command via both SQL and HTTP protocols:

‹›

SQL
JSON
PHP
Python
Python-asyncio
Javascript
Java
C#
Rust
Typescript
Go
CONFIG

📋

CREATE TABLE products(title text, price float) morphology='stem_en';

POST /sql?mode=raw -d "CREATE TABLE products(title text, price float)  morphology='stem_en'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'float'],
]);

utilsApi.sql('CREATE TABLE forum(title text, price float)')

await utilsApi.sql('CREATE TABLE forum(title text, price float)')

res = await utilsApi.sql('CREATE TABLE forum(title text, price float)');

utilsApi.sql("CREATE TABLE forum(title text, price float)");

utilsApi.Sql("CREATE TABLE forum(title text, price float)");

utils_api.sql("CREATE TABLE forum(title text, price float)", Some(true)).await;

res = await utilsApi.sql('CREATE TABLE forum(title text, price float)');

utilsAPI.Sql(context.Background()).Body("CREATE TABLE forum(title text, price float)").Execute()

table products {
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
  stored_fields = title
}

‹›

Response

Query OK, 0 rows affected (0.00 sec)

NOTE: The _mapping API requires Manticore Buddy. If it doesn't work, make sure Buddy is installed.

Alternatively, you can create a new table via the _mapping endpoint. This endpoint allows you to define an Elasticsearch-like table structure to be converted to a Manticore table.

The body of your request must have the following structure:

"properties"
{
  "FIELD_NAME_1":
  {
    "type": "FIELD_TYPE_1"
  },
  "FIELD_NAME_2":
  {
    "type": "FIELD_TYPE_2"
  },
  ...
  "FIELD_NAME_N":
  {
    "type": "FIELD_TYPE_M"
  }
}

When creating a table, Elasticsearch data types will be mapped to Manticore types according to the following rules:

aggregate_metric => json
binary => string
boolean => bool
byte => int
completion => string
date => timestamp
date_nanos => bigint
date_range => json
dense_vector => json
flattened => json
flat_object => json
float => float
float_range => json
geo_point => json
geo_shape => json
half_float => float
histogram => json
integer => int
integer_range => json
ip => string
ip_range => json
keyword => string
knn_vector => float_vector
long => bigint
long_range => json
match_only_text => text
object => json
point => json
scaled_float => float
search_as_you_type => text
shape => json
short => int
text => text
unsigned_long => int
version => string

‹›

JSON

JSON

📋

⚙

POST /your_table_name/_mapping -d '
{
  "properties": {
    "price": {
        "type": "float"
    },
    "title": {
        "type": "text"
    }
  }
}
'

‹›

Response

{
"total":0,
"error":"",
"warning":""
}

You can create a copy of a real-time table, with or without its data. Please note that if the table is large, copying it with data may take some time. Copying works in synchronous mode, but if the connection is dropped, it will continue in the background.

CREATE TABLE [IF NOT EXISTS] table_name LIKE old_table_name [WITH DATA]

NOTE: Copying a table requires Manticore Buddy. If it doesn't work, make sure Buddy is installed.

‹›

SQL
Example (WITH DATA)
JSON
JSON example (WITH DATA)

📋

create table products LIKE old_products;

create table products LIKE old_products WITH DATA;

POST /sql?mode=raw -d "create table products LIKE old_products"

POST /sql?mode=raw -d "create table products LIKE old_products WITH DATA"

Add documents.
Update attributes and full-text fields using the Update process.
Delete documents.
Empty the table.
Change the schema online with the ALTER command, as explained in Change schema online.
Define the table in a configuration file, as detailed in Define table.
Use automatic ID generation.

Ingest data using the indexer feature.
Connect it to sources for easy indexing from external storage.
Update the killlist_target, as it is automatically managed by the real-time table.

The following table outlines the different file extensions and their respective descriptions in a real-time table:

Extension	Description
`.lock`	A lock file that ensures that only one process can access the table at a time.
`.ram`	The RAM chunk of the table, stored in memory and used as an accumulator of changes.
`.meta`	The headers of the real-time table that define its structure and settings.
`..sp`	Disk chunks that are stored on disk with the same format as plain tables. They are created when the RAM chunk size exceeds the rt_mem_limit.

For more information on the structure of disk chunks, refer to the plain table files structure.

Creating a local table Plain table

Last modified: July 20, 2026

Data types

Full-text fields and attributes

Table and field name syntax

Full-text fields

Attributes

Row-wise and columnar attribute storages

How to switch between the storages

Document ID

Interface differences with large IDs

UUID document IDs

Character data types

Text

String

Storing binary data in Manticore

Integer

Big Integer

Boolean

Timestamps

Float

JSON

Float vector

General Limitations

Using Float Vectors with KNN (Vector Search)

Capabilities

Parameters

Method 1: Auto Embeddings (Recommended)

Benefits of Auto Embeddings

Creating tables with auto embeddings

FROM parameter usage

Inserting data with auto embeddings

Method 2: Manual Vector Insertion

Method 3: Add an embedding column after bulk loading

Using Float Vectors without KNN (Storage Only)

Use Cases

Float vector array

Value syntax

General limitations

Using float vector arrays with KNN

Using float vector arrays without KNN

Multi-value integer (MVA)

Multi-value big integer

Columnar attribute properties

fast_fetch

Data types

Full-text fields and attributes

Table and field name syntax

Full-text fields

Attributes

Row-wise and columnar attribute storages

How to switch between the storages

Document ID

Interface differences with large IDs

UUID document IDs

Character data types

Text

String

Storing binary data in Manticore

Integer

Big Integer

Boolean

Timestamps

Float

JSON

Float vector

General Limitations

Using Float Vectors with KNN (Vector Search)

Capabilities

Parameters

Method 1: Auto Embeddings (Recommended)

Benefits of Auto Embeddings

Creating tables with auto embeddings

FROM parameter usage

Inserting data with auto embeddings

Method 2: Manual Vector Insertion

Method 3: Add an embedding column after bulk loading

Using Float Vectors without KNN (Storage Only)

Use Cases

Float vector array

Value syntax

General limitations