Skip to main content

Features

This page summarizes the current hlquery feature set and points to the route families where each capability is exposed.

hlquery provides token-based full-text search with BM25-style scoring and configurable query controls.

Primary route:

GET/POST /collections/{collection}/documents/search

Supported request controls include:

  • q query text
  • query_by searchable fields
  • filter_by filters
  • sort_by sorting
  • facet_by facets
  • geo radius, bounding-box, and distance-sort controls
  • highlight, highlight_fields, and highlight_full_fields
  • page/per_page and limit/offset
  • typo/fuzzy controls such as num_typos
  • distributed execution overrides where configured

The query parser supports field terms, ranges, boosts, fuzzy suffixes, boolean-style controls, and highlighting options. See Search API for examples.

Geo fields can be declared with geo_point, geopoint, geo, or latlon. Search supports _geo_radius(...) and _geo_box(...) filters plus _geo_distance(...):asc|desc sorting. Geo filtering is exact post-processing over candidate hits; it is not yet backed by a spatial index.

Vector search is exposed through:

GET/POST /collections/{collection}/vector_search
GET/POST /collections/{collection}/search

The /collections/{collection}/search path is a vector-search alias. Lexical search uses /collections/{collection}/documents/search.

Vector search supports:

  • raw vector payloads
  • vector_query
  • vector_queries
  • dense array vectors
  • sparse object-form vectors
  • metrics such as cosine, dot, l2, and l1
  • filter_by
  • output_fields
  • include_vector
  • threshold, radius, and distance controls
  • fusion methods for multi-vector requests

The current implementation uses exact linear scanning over candidates rather than an ANN index. See Vector Search API.

Hybrid search combines lexical and vector signals through the shared search/vector pipeline when vector fields and hybrid parameters are present.

Common controls:

  • hybrid_alpha
  • q
  • query_by
  • vector_query
  • vector request fields

Use lower hybrid_alpha values to favor lexical scoring and higher values to favor vector similarity.

Batch and global entry points:

GET/POST /multi_search
GET/POST /search
GET/POST /sql

/multi_search accepts multiple searches in one request. /search is a global search entry point. /sql accepts SQL-style queries and execution payloads.

Data Management​

Collections​

Collections are schema containers for documents.

Routes:

GET/POST /collections
GET/DELETE /collections/{collection}
GET /collections/{collection}/lang
POST /collections/{collection}/update
GET /collections/distributed

Supported field types include text, numeric, boolean, string arrays, and float arrays for vectors. See Collections API.

Documents​

Document operations include:

GET/POST/DELETE /collections/{collection}/documents
GET/PUT/DELETE /collections/{collection}/documents/{id}
GET /collections/{collection}/documents/{id}/context
POST /collections/{collection}/documents/import
POST /collections/{collection}/documents/_update_by_query
POST /collections/{collection}/documents/_delete_by_query
GET/POST /collections/{collection}/documents/export

Use bulk import for high-volume indexing and by-query writes for controlled maintenance workflows. See Documents API.

Aliases​

Aliases provide stable names for collection targets:

GET /aliases
GET /collections/{collection}/aliases
POST/PUT /aliases/{alias}
GET /aliases/{alias}
DELETE /aliases/{alias}

Aliases are useful for reindexing workflows where clients should keep querying a stable name while the target collection changes. See Aliases API.

Relevance Controls​

Synonyms​

Synonyms can be managed globally or per collection:

GET /synonyms
GET /synonyms/global
POST/PUT /synonyms/global/{id}
GET/DELETE /synonyms/global/{id}
GET /collections/{collection}/synonyms
POST/PUT /collections/{collection}/synonyms/{id}
GET/DELETE /collections/{collection}/synonyms/{id}

Stopwords​

Stopwords can also be global or collection-specific:

GET /stopwords
GET/POST /stopwords/global
DELETE /stopwords/global/{word}
GET/POST /collections/{collection}/stopwords
DELETE /collections/{collection}/stopwords/{word}

Overrides​

Overrides store query-specific relevance rules:

GET /collections/{collection}/overrides
POST/PUT /collections/{collection}/overrides/{id}
GET/DELETE /collections/{collection}/overrides/{id}

See Synonyms, Stopwords, and Overrides.

Operations​

Health, Metrics, and Storage​

Built-in runtime endpoints include:

/health
/ready
/ping
/status
/startup
/stats
/metrics
/metrics/history
/connections
/doctotal
/rocksdb
/admin/storage_status

Maintenance endpoints include:

/update-counters
/debug/counters
/repair
/integrity
/consistency
/self-check
/flush

See System Endpoints.

Cluster link endpoints:

GET /links
GET /links/ping
POST /links/connect
POST /links/disconnect

Distributed collection listing is available at:

GET /collections/distributed

Modules​

Runtime modules are exposed through:

GET /modules
POST /loadmodule
POST /loadmodule/{module}
POST /unloadmodule
POST /unloadmodule/{module}
GET /modules/{module}/syntax
GET/POST/PUT/DELETE /modules/{module}/...

Extra modules are enabled at build time with ./configure --enable-extras=....

Security​

API Keys​

API keys support:

  • collection-level scopes
  • action-level permissions
  • embedded filters
  • rate limits
  • optional hanalyzer access through allow_hanalyzer

Users​

Named users can be managed with /users and support user and admin flags.

IP Filtering​

IP filtering supports allow/deny configuration for direct IPs, CIDR ranges, hostnames, and wildcard hostnames.

Tooling​

  • hlquery-cli for command-line operations
  • talk REPL for interactive shell workflows
  • hanalyzer web UI for collection, document, and search inspection
  • language clients for Node.js, Python, PHP, Perl, Rust, C++, and other integrations in this repository

Current Limits​

  • Vector search currently uses exact scan rather than ANN indexing.
  • Some module APIs depend on which modules were built and loaded.
  • LLM routes depend on runtime configuration and local model availability.
  • Production behavior should be validated with your own dataset, traffic pattern, storage backend, and enabled modules.

For endpoint details, start with API Overview and Complete API Reference.