Which document, vector and AI features each edition ships today, and what is planned
Most databases treat document storage, vector search, and AI as separate add-ons requiring external infrastructure. HeliosDB treats them as first-class citizens across every edition -- from a Nano instance you try in your browser to a HeliosDB Full server. The editions differ in how far they scale and in which features ship today; rows marked Planned below are on the roadmap and not in a current release.
Correction (2026-09-11): earlier revisions of this page described Nano as compiling to WASM and running client-side in the browser. That is not accurate — Nano has no WebAssembly build target. To try Nano from a browser, use the SQL Playground: it runs an embedded Nano instance on the server, one per session.
| Capability | Nano (Embedded/Edge) | Lite (Embedded/Server) | Full (Enterprise) |
|---|---|---|---|
| File storage API (Supabase Storage-style buckets, signed URLs) | Planned | Planned | Planned |
| Document ingest REST API | Planned | Planned | Yes (POST /api/v1/documents) |
| Document Chunking | Planned (with the document-ingest API) | Planned (with the document-ingest API) | Fixed-size character chunks with overlap |
| Semantic Search | Yes | Yes | Yes |
| RAG Pipeline | Planned (Graph-RAG retrieval with WITH CONTEXT ships as a source-build feature) | Planned | Planned (document search, hybrid search and chat completions over the HTTP gateway today) |
| AI Providers | Planned (roadmap): OpenAI, Anthropic, Local, HuggingFace, Custom | Planned (roadmap) | Planned (roadmap) |
| Vector Search | HNSW + PQ in the default build, in memory (durable PQ-HNSW: vector-persist build) | HNSW + PQ + SIMD | HNSW over the HTTP vector-store API (SQL vector indexes and distributed search planned) |
| ACID Transactions | Single-node | Full MVCC | MVCC on a single node (distributed MVCC planned) |
| Time-Travel Queries | Limited | Full | Planned (the current release accepts AS OF but does not read historical snapshots) |
| Branch Isolation | SQL branches (copy-on-write) | Native branches | Planned (the current release accepts the syntax but does not create branches) |
| Encryption at Rest | AES-256-GCM TDE, off by default, needs a key | TDE (AES-256-GCM) | Planned (with key rotation and cloud KMS) |
| MongoDB clients | -- | -- | Listener accepts connections and authentication; reading and writing HeliosDB tables through it is planned |
| Foreign Data Wrappers | -- | -- | Planned |
| Change Streams | -- | -- | Planned |
| Deployment Target | Embedded, IoT, Edge; try it server-side in a browser via the SQL Playground | Server, Desktop, Container | Server, Container (multi-node cluster planned) |
| Binary Size | ~15-17 MB compressed download (current release assets) | Single binary; size depends on the build features | Single binary; size depends on the build features |
| Code-Graph, Graph-RAG, MCP server | Build-from-source features (hdb_code, WITH CONTEXT, native MCP server) | Planned | Planned |
| GPU acceleration | -- | -- | NVIDIA CUDA in Full builds on request, not enabled in the public release build; AMD ROCm planned |
| Configuration | Zero-config | Zero-config | Config file or env vars |
Nano is a single small binary built for constrained and edge deployments — IoT devices, edge nodes, and desktop/mobile apps. It does not compile to WASM or run natively inside a browser.
File storage (buckets and signed URLs) and edge functions are on the HeliosDB roadmap; today Nano serves PostgREST-style REST, auth and a realtime WebSocket, and stores data in its data directory. The /rest/v1 table routes are a known issue in the current release. Known issue: realtime events are not delivered in the current release; tracked by the Nano team. Keep the HTTP and MySQL listeners on loopback (the default): API-key authentication for the HTTP API is planned, and a smaller listening surface is good practice anyway. Store document text in table rows next to its embeddings, as the examples below do.
Correction (2026-10-14): earlier revisions of this page showed a Supabase Storage client creating buckets, uploading files and signing URLs against Nano, and listed the Supabase Storage API as available in all three editions. No edition serves that API today; it is planned.
A document-ingest REST API for Nano (store a document, split it into chunks, embed them and search them over HTTP) is planned; the current /v1/documents routes are mounted but do not store documents yet. Today, store document text and its chunks in tables next to their embeddings and search them with SQL over the PostgreSQL wire protocol, as the examples below do. HeliosDB Full ingests, chunks and embeds documents at POST /api/v1/documents on its HTTP gateway, splitting the text into fixed-size character chunks with overlap (chunk_size, default 800; chunk_overlap, default 100).
Correction (2026-10-15): earlier revisions of this page described a Nano Document Handler that ingests, chunks with four strategies and embeds documents over HTTP. The routes for it in the current release are not functional; the API is planned.
A built-in retrieval-to-generation pipeline is planned for Nano. Retrieval ships today: vector search and BM25-ranked full-text search in SQL, and Graph-RAG expansion with WITH CONTEXT in the graph-rag source build. Pass the rows you retrieve to the LLM client you already use.
-- Retrieve the passages to ground an answer
SELECT title, content,
0.7 * (1.0 - (embedding <=> $1::vector(1536)))
+ 0.3 * ts_rank_cd(to_tsvector(content), plainto_tsquery($2)) AS score
FROM document_chunks
ORDER BY score DESC
LIMIT 5;Correction (2026-10-15): earlier revisions of this page showed a /api/v1/rag/query call on port 3000, Lite branching and encryption through helios_branch_* and helios_tde_init functions, an auto_embed column, and helios dump / helios-full restore commands. None of these exists in any edition; this page now shows the real statements and the planned items.
Built-in AI provider routes for Nano (HTTP chat, embeddings, text-embedding vectors and NL-to-SQL) are planned (roadmap). Built-in provider configuration is on the roadmap for Lite and Full as well. The planned configuration covers five providers, so you can switch between them without changing application code:
// OpenAI
{ "provider": "openai", "model": "gpt-4o", "api_key": "sk-..." }
// Anthropic
{ "provider": "anthropic", "model": "claude-sonnet-4-20250514", "api_key": "sk-ant-..." }
// Local LLM (Ollama, llama.cpp, vLLM)
{ "provider": "local", "endpoint": "http://localhost:11434", "model": "llama3.2" }
// HuggingFace Inference
{ "provider": "huggingface", "model": "mistralai/Mixtral-8x7B", "api_key": "hf_..." }
// Custom endpoint (any OpenAI-compatible API)
{ "provider": "custom", "endpoint": "https://my-model.internal/v1", "model": "my-fine-tune" }On IoT and edge hardware, Nano persists to a regular data directory on whatever filesystem the device provides — there is no browser storage backend (IndexedDB/OPFS/LocalStorage), because there is no browser involved.
Nano's copy-on-write SQL branches give document pipelines Git-style isolation: stage edits on a branch, then merge them back into main.
-- Stage a draft on its own branch
CREATE BRANCH drafts_annual_report;
USE BRANCH drafts_annual_report;
UPDATE documents SET content = 'Updated Q4 report with December actuals'
WHERE title = 'Q4 Report';
-- When approved, merge it back
MERGE BRANCH drafts_annual_report INTO main;Lite is the embedded edition designed for server-side applications, desktop software, and containerized microservices. It adds ACID transactions, hardware-accelerated vector search, encryption, and time-travel to the document stack.
Lite builds on the same SQL core as Nano and adds the features below on top. Like Nano, it has no file storage API yet; buckets and signed URLs are planned. Code-Graph, Graph-RAG and the MCP server are planned for Lite and Full; see the table above.
Lite uses a three-layer vector search architecture optimized for server hardware:
-- Connect via PostgreSQL wire protocol (psql, any PG driver)
-- Create a table with vector embeddings
CREATE TABLE documents (
id SERIAL PRIMARY KEY,
title TEXT NOT NULL,
content TEXT,
category TEXT,
embedding VECTOR(1536),
created_at TIMESTAMP DEFAULT NOW()
);
-- Create an HNSW index for fast approximate nearest-neighbor search
CREATE INDEX idx_docs_embedding ON documents
USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 200);
-- Semantic search: find the 10 most similar documents
SELECT id, title, category,
embedding <=> '[0.1, -0.3, 0.5, ...]'::vector AS distance
FROM documents
ORDER BY embedding <=> '[0.1, -0.3, 0.5, ...]'::vector
LIMIT 10;Vector search internals:
| Component | Purpose |
|---|---|
| HNSW (Hierarchical Navigable Small World) | Graph-based approximate nearest-neighbour index |
| Product Quantization | Compresses vectors so larger datasets fit in memory |
| SIMD Acceleration | AVX2/SSE4 for distance computations on x86; NEON on ARM |
Every document operation participates in MVCC transactions -- including chunking and embedding:
import psycopg2
conn = psycopg2.connect("host=localhost port=5432 dbname=helios")
cur = conn.cursor()
try:
# All three operations are atomic
cur.execute("""
INSERT INTO documents (title, content, embedding)
VALUES ('Q4 Report', %s, %s)
""", (report_text, embedding_vector))
cur.execute("""
INSERT INTO document_chunks (doc_id, chunk_index, content, embedding)
SELECT currval('documents_id_seq'), idx, chunk, embed
FROM unnest(%s::text[], %s::vector[]) WITH ORDINALITY AS t(chunk, embed, idx)
""", (chunks, chunk_embeddings))
cur.execute("""
INSERT INTO document_metadata (doc_id, key, value)
VALUES (currval('documents_id_seq'), 'status', '"published"')
""")
conn.commit() # All-or-nothing: document + chunks + metadata
except Exception:
conn.rollback() # Nothing written on failureQuery any document as it existed at any point in the past:
-- What did the contract say last Tuesday?
SELECT title, content
FROM documents
AS OF TIMESTAMP '2026-02-10 14:30:00'
WHERE title = 'Service Agreement v3';
-- Compare two versions of a document
SELECT
old.content AS previous_version,
new.content AS current_version
FROM documents AS OF TIMESTAMP '2026-01-15' old
JOIN documents new ON old.id = new.id
WHERE new.title = 'Privacy Policy';Create isolated branches to stage document changes without affecting production:
-- Create a review branch (AS OF is optional)
CREATE BRANCH review_legal_update FROM main AS OF NOW;
-- Switch to the branch
USE BRANCH review_legal_update;
-- Make changes on the branch (invisible to main)
UPDATE documents SET content = 'Updated terms...'
WHERE title = 'Terms of Service';
-- When approved, switch back and merge
USE BRANCH main;
MERGE BRANCH review_legal_update INTO main;In Lite, USE BRANCH switches the branch for all sessions on the server; per-session branch selection is planned, so stage branch edits from a maintenance session.
Lite encrypts stored rows with AES-256-GCM Transparent Data Encryption. Encryption at rest takes effect only when it is enabled in the configuration with a key source; it is off by default:
# heliosdb.toml (encryption is off by default)
[encryption]
enabled = true
[encryption.key_source]
Environment = "HELIOSDB_ENCRYPTION_KEY"No application code changes are needed: queries run unchanged and decryption is transparent.
| Attribute | Value |
|---|---|
| Binary size | Single binary; size depends on the build features |
| Configuration | Zero-config (single binary) |
| Protocol | PostgreSQL wire protocol (any PG client) |
| Concurrency | Multi-threaded MVCC |
| Storage backend | O_DIRECT (bypass OS page cache) |
| Max dataset | Limited by disk |
Full is the enterprise edition for organizations that need more wire protocols and retrieval over an HTTP gateway; in-database machine learning is planned. It runs as a single node today; multi-node clustering is planned.
Full shares the SQL core and ACID transactions described for Lite and serves vector search through its HTTP gateway. Nano and Lite run time-travel queries (AS OF) and Git-like branches; for HeliosDB Full both are planned (the current release accepts the syntax but does not read historical snapshots or create branches), and so is encryption at rest. The file storage API (buckets and signed URLs) is planned for Full as well.
HeliosDB Full opens listeners for PostgreSQL, MySQL, Oracle, MongoDB, Cassandra, Redis and SQL Server plus an HTTP gateway; MongoDB, Cassandra and SQL Server clients can connect and authenticate, and reading and writing HeliosDB tables through them is planned. A MongoDB-style document API with query operators, aggregation pipelines and change streams is therefore on the roadmap, not in the current release. For document workloads today, store JSON in tables and query it over the PostgreSQL wire protocol.
Correction (2026-10-14): earlier revisions of this page showed a Python document-store client running find, aggregation pipelines and change streams against Full. Those reads are not served by the current release; they are planned.
Querying Parquet, CSV and JSON files on S3 or MinIO, and tables in other databases, through foreign tables is planned for HeliosDB Full. Today, load the data you query into HeliosDB tables over the PostgreSQL wire protocol and keep the files in object storage; an S3-compatible object API for HeliosDB Full is on the roadmap and is not part of the current release.
HeliosDB Full's HTTP gateway ingests and searches documents, serves vector stores with hybrid search (POST /api/v1/vectors/stores/{store}/search/hybrid) and forwards chat completions to a configured provider. Graph-RAG for HeliosDB Full is planned. The HeliosDB SDKs target the Nano and Lite REST API, so from application code reach Full with a PostgreSQL driver or plain HTTP.
Correction (2026-10-14): earlier revisions of this page showed CREATE SERVER / CREATE FOREIGN TABLE over an S3 foreign data wrapper, a table of seven foreign data wrappers and a Python RagEngine client for Full. The current release serves none of these; foreign data wrappers are planned, and the SDKs have no RagEngine class.
HeliosDB Full runs as a single node today; Raft consensus, replication, multi-region deployment and sharding are planned.
HeliosDB unifies four capabilities that have historically required separate systems, separate infrastructure, and complex ETL pipelines:
Documents are not blobs stored alongside the database -- they are in the database, governed by the same MVCC transactions, constraints, and recovery guarantees as every other row.
Vector indexes (HNSW with Product Quantization and SIMD acceleration) run in the same process as the query engine. There is no network hop to a separate vector database, no synchronization lag, no eventual consistency between your documents and their embeddings.
Write a document and its embedding in the same row and the same transaction, so there is no window of time where the document exists but its embedding does not. Automatic chunking and embedding on INSERT is planned; today your application computes the embedding and writes it with the row.
-- Document and embedding commit together
BEGIN;
INSERT INTO documents (title, content, embedding)
VALUES ('Quarterly Report', 'Full report text here...', $1::vector(1536));
COMMIT;
-- Immediately searchable: keyword filter + vector ranking
SELECT title, embedding <=> $2::vector(1536) AS distance
FROM documents
WHERE to_tsvector(content) @@ plainto_tsquery('revenue growth')
ORDER BY distance
LIMIT 5;HeliosDB connects to local language models (Ollama, llama.cpp, vLLM) running on the same machine or network. Documents never leave the perimeter. Built-in provider routes for Nano are planned (roadmap); with Nano today, pass the rows you retrieve to the local model client you already run. This enables:
A typical document AI stack without HeliosDB:
| Component | Product | Purpose |
|---|---|---|
| Document storage | S3 / MinIO | Store blobs |
| Metadata database | PostgreSQL | Track document metadata |
| Vector database | Pinecone / Weaviate | Store embeddings |
| Embedding pipeline | Airflow + OpenAI API | Generate vectors |
| Search engine | Elasticsearch | Full-text search |
| RAG framework | LangChain / LlamaIndex | Orchestrate retrieval + generation |
| Message queue | Kafka / SQS | Glue everything together |
Seven systems, seven failure modes, seven bills, eventual consistency between all of them.
With HeliosDB, this becomes one binary, one connection string, one transaction boundary.
Nano, Lite and Full are separate products with their own storage and deployment models. They share the PostgreSQL wire protocol and most of the SQL dialect, so client code is largely portable, but they do not share an on-disk format, and there is no published automated import path between editions. Moving between them is a logical export and reload over the PostgreSQL wire, not a file copy; talk to sales and we will scope the move against your deployment (see the migration guide).
A file storage API (buckets and signed URLs) is planned for all three editions.
Get started with HeliosDB in minutes. Nano and HeliosProxy are open source (Apache 2.0); Lite and Full are licensed through sales.