HeliosDB vs MinIO AIStor

Choose HeliosDB Full when you want SQL tables and vector stores with hybrid search on the same server as your data (in-database machine learning is planned); keep MinIO AIStor when S3 object storage, petabyte-scale blob storage, erasure-coded durability, an Iceberg catalog or an existing ML platform is the main requirement. HeliosDB Full does not offer an S3 API today, so the two sit side by side rather than one replacing the other.

MinIO AIStor is MinIO's enterprise rebrand -- the same S3-compatible object store with Iceberg table support, webhook-based "AI hooks" (promptObject), and integrations to external ML services. It positions itself as "AI storage infrastructure." HeliosDB Full is a multi-protocol SQL database whose HTTP gateway serves vector stores with hybrid search, document ingest, embeddings and chat completions; in-database ML training, anomaly detection and autonomous agents are planned. AIStor connects to AI tools; HeliosDB Full serves retrieval next to the data.

---

Quick Comparison

Cells are keyed to the fuller notes below — read the note before treating a short cell as the whole story.

Notes, row by row

Query language

AIStor exposes S3 Select, which filters a single file at a time. HeliosDB runs full SQL: JOINs, CTEs, window functions, and subqueries.

Vector search

AIStor stores embeddings but searches them in an external engine such as Milvus or LanceDB. HeliosDB Full keeps them in HNSW vector stores with hybrid search on its HTTP gateway; vector indexes in SQL are planned.

RAG pipelines

AIStor's promptObject hooks out to external LLMs. HeliosDB Full's HTTP gateway ingests and searches documents, serves vector stores with hybrid search and forwards chat completions to a configured provider; Graph-RAG for HeliosDB Full is planned.

ML model training

AIStor expects an external framework (PyTorch, TensorFlow). In-database model training for HeliosDB Full is planned.

Autonomous agents

Cognitive agents for tuning, healing, data quality, optimization and security are planned for HeliosDB Full. AIStor has no equivalent.

Anomaly detection

Anomaly detection in the engine is planned for HeliosDB Full.

Natural language queries

NL-to-SQL and conversational BI are planned for HeliosDB Full. AIStor has no equivalent.

ML-based data tiering

AIStor moves data with manual lifecycle rules. ML-driven tiering for HeliosDB Full is planned with the S3-compatible object API.

Threat detection

Threat scanning on ingest is planned with the S3-compatible object API.

Protocol adapters

AIStor speaks S3 plus the Iceberg REST catalog. HeliosDB Full opens listeners for PostgreSQL, MySQL, Oracle, MongoDB, Cassandra, Redis and SQL Server plus an HTTP gateway (protocol hub). MongoDB, Cassandra and SQL Server clients can connect and authenticate, and reading and writing HeliosDB tables through them is planned; the Redis listener keeps data in memory. An S3-compatible object API is on the roadmap and is not part of the current release.

ACID transactions

AIStor guarantees single-object atomicity. HeliosDB runs multi-statement MVCC at Serializable isolation.

Triggers / UDFs

AIStor offers webhook-based events only. HeliosDB Full runs PL/pgSQL; WASM procedures are planned.

Graph database

Cypher and GQL over a property graph model are planned for HeliosDB Full.

Time-travel

AIStor keeps linear object versions. 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).

Encryption

AIStor offers SSE-S3, SSE-KMS, and SSE-C. For HeliosDB Full, encryption at rest with key rotation and cloud KMS is planned; post-quantum TLS arrives with native PostgreSQL TLS in the next release, and Kyber/Dilithium data encryption is planned (edition comparison).

Compliance

AIStor's compliance posture is basic — SOC2 via an enterprise contract. A built-in compliance framework for SOC 2, HIPAA, GDPR and PCI-DSS controls is planned for HeliosDB Full; HeliosDB's own SOC 2 Type II audit is in progress and ISO 27001 certification is planned (compliance matrix).

---

"AI-Native" -- What It Actually Means

MinIO AIStor calls itself "AI storage infrastructure." In practice, this means it stores objects and fires webhooks to external AI services. Every intelligence capability -- embeddings, search, training, inference -- lives in a separate process that you deploy, configure, and maintain yourself. AIStor is a storage layer with hooks, not an AI system.

HeliosDB Full takes a different approach: its retrieval features run in the same server as its SQL tables, so there is one service to deploy for both. In-database model training is planned.

MinIO AIStor: Storage + External AI Services

+------------------+
|   MinIO AIStor   |   (stores objects, fires webhooks)
+--------+---------+
         |
         | promptObject / webhooks / S3 notifications
         |
    +----+-----+     +-----------+     +------------+
    | PyTorch  |     |  Milvus   |     | LangChain  |
    | (train)  |     | (vectors) |     |   (RAG)    |
    +----------+     +-----------+     +------------+
         |                |                  |
    +----+-----+     +----+------+     +-----+------+
    | TensorFlow|    |  LanceDB  |     | External   |
    | (infer)  |     | (backup)  |     |   LLM API  |
    +----------+     +-----------+     +------------+

 6+ services to deploy, monitor, version, and keep alive
 No ACID across the pipeline
 Latency: network hop on every AI operation
 Failure domain: any service down = pipeline broken

HeliosDB Full: SQL and Retrieval on One Server

HeliosDB Full serves its SQL tables over the PostgreSQL, MySQL and Oracle listeners and, from the same server, an HTTP gateway with vector stores, hybrid search, document ingest, embeddings, chat completions and agent memory. In-database model training, NL-to-SQL and autonomous agents are planned.

---

Vector Search: External vs Native

MinIO AIStor: Store Embeddings Elsewhere

AIStor has no vector index. To do similarity search, you store embeddings in Milvus, LanceDB, or Weaviate -- services that use AIStor as their blob backend. The result is two separate query paths with no ACID consistency between them.

# AIStor + Milvus: two systems, two queries, no ACID

# Step 1: Store raw document in AIStor
s3.put_object(Bucket='docs', Key='report.pdf', Body=pdf_bytes)

# Step 2: Generate embedding externally
embedding = openai.embeddings.create(input=text, model='text-embedding-3-small')

# Step 3: Store embedding in Milvus (which itself uses AIStor for persistence)
milvus.insert(collection='documents', data=[{
    'embedding': embedding.data[0].embedding,
    's3_key': 'report.pdf'
}])

# Step 4: Search requires querying Milvus, then fetching from AIStor
results = milvus.search(
    collection='documents',
    data=[query_embedding],
    limit=5,
    output_fields=['s3_key']
)

# Step 5: Fetch actual documents from AIStor
for hit in results[0]:
    obj = s3.get_object(Bucket='docs', Key=hit.entity.get('s3_key'))
    # ... process

# Problems:
#  - Document deleted from AIStor? Milvus still returns it (stale index)
#  - Milvus insert fails? Document exists without embedding (orphan)
#  - No transactional guarantee across the two systems
#  - Network round-trip on every search + fetch

HeliosDB Full: Vector Stores on the Same Server

HeliosDB Full keeps embeddings in vector stores on its HTTP gateway and searches them with hybrid search (POST /api/v1/vectors/stores/{store}/search/hybrid), next to the SQL tables on the same server. Vector columns, HNSW indexes and distance operators in SQL, so that a row and its embedding change in one transaction, are planned for HeliosDB Full.

---

RAG Pipelines

MinIO AIStor: promptObject -- A Thin Wrapper

AIStor's "AI feature" is promptObject: a webhook-style API that sends an object's content to an external LLM and returns the response. It does not chunk, embed, index, rerank, or cache. It is an HTTP proxy to an LLM endpoint.

# AIStor promptObject: send object to external LLM
import requests

response = requests.post('http://aistor:9000/prompt', json={
    'bucket': 'docs',
    'key': 'report.pdf',
    'prompt': 'Summarize this document',
    'model': 'gpt-4'  # external LLM required
})

# What promptObject does NOT do:
#  - Chunk the document intelligently
#  - Generate or store embeddings
#  - Perform multi-source retrieval
#  - Rerank results by relevance
#  - Cache responses
#  - Support graph-based RAG
#  - Handle multi-turn conversations
#
# For real RAG, you still need:
#  LangChain + Milvus + embedding API + chunking logic + reranking model

HeliosDB Full: Retrieval Over the HTTP Gateway

Retrieval in SQL, with vector and full-text scores fused in one query, is planned for HeliosDB Full.

The HTTP gateway also serves vector stores with hybrid search (POST /api/v1/vectors/stores/{store}/search/hybrid), document ingest and search, and chat completions forwarded to a configured provider. Graph-RAG for HeliosDB Full is planned.

---

Autonomous Intelligence (planned)

AIStor expects you to tune, scale and secure your infrastructure manually. Cognitive agents for HeliosDB Full (performance tuning, self-healing, data quality, query optimization and security response) are planned; the current server does not start them, so plan to tune and monitor HeliosDB Full yourself today.

---

Does HeliosDB Full replace an S3 store?

Not today. An S3-compatible object API for HeliosDB Full is on the roadmap and is not part of the current release. The bucket-management SQL statements described in earlier release notes (CREATE BUCKET, lifecycle rules, natural-language policies, presign_url(), object lock and legal hold, threat scans and MIGRATE BUCKET) are planned together with it; do not rely on them for retention or legal hold (release notes · protocol hub).

---

When to Choose Each

Choose MinIO AIStor When:

• Petabyte-scale blob storage is the primary need -- You are storing training datasets, model checkpoints, video archives, or backup tarballs and need raw throughput at minimal cost
• You already have a mature ML platform -- Your team runs Kubeflow, MLflow, or SageMaker and needs a fast S3-compatible backend for those tools
• Iceberg table catalog -- You use Apache Iceberg with Spark/Trino/Flink and need a catalog + storage backend
• Erasure-coded durability -- You want drive-failure tolerance without full replication overhead on large binary objects
• Your AI code is already written -- Your pipeline is in production with LangChain, Milvus, and PyTorch -- and you just need better storage under it

Choose HeliosDB When:

• Retrieval next to the data -- You want vector stores, hybrid search, document ingest and chat completions served by the same server as your SQL tables; in-database ML training and anomaly detection are planned
• You need to query your data -- Full SQL with JOINs, CTEs, window functions, aggregations, and subqueries across all data types
• Multi-protocol access -- The same tables reachable from PostgreSQL, MySQL and Oracle clients and the HTTP gateway; MongoDB, Cassandra and SQL Server clients can connect and authenticate, and reading and writing tables through them is planned (protocol hub)
• Fewer services -- One licensed server for SQL and vector retrieval instead of separate SQL, vector and RAG services

---

When HeliosDB is not the right fit

These limits apply to HeliosDB Full, the edition this page compares. If you are looking at the embedded HeliosDB Nano instead, note that in the stock Nano server, row-level security is enforced through the embedded API and the REPL; SQL CREATE POLICY and enforcement for REST and wire clients are planned (Nano deployment modes).

• You need an S3 API. An S3-compatible object API for HeliosDB Full is on the roadmap and is not part of the current release, and the bucket-management SQL in earlier release notes is planned with it. Release notes · Protocol hub
• You need certified compliance today. HeliosDB's SOC 2 Type II audit is in progress and ISO 27001 certification is planned. Compliance matrix
• You need protocols beyond the documented listeners. heliosdb-full opens no GraphQL, ClickHouse, DB2 or Pinecone listener, and /snowflake/ paths answer 501; those interfaces are on the roadmap, and today the same data is reached over PostgreSQL or POST /api/v1/query. Protocol compatibility matrix
• You need proof at large or multi-node scale. Published HeliosDB benchmarks are single-node on a small dataset; large-dataset and distributed results are not yet published. Benchmarks
• You need a multi-node cluster today. HeliosDB Full runs as a single server today; Raft clustering, multi-region replication and sharding are planned. HeliosDB Full
• You need TLS on the database listeners. HeliosDB Full listeners do not terminate TLS today; put a TLS-terminating proxy in front. Native PostgreSQL TLS (with post-quantum key exchange preferred) is planned. Protocol hub
• You need an open-source licence. HeliosDB Full is source-available under SSPL-1.0 and licensed through sales. Full FAQ: licensing · Pricing

---

Migration Path

Moving from AIStor to HeliosDB Full today means loading the data you query into tables, not switching an S3 endpoint: the S3-compatible object API and MIGRATE BUCKET are on the roadmap and are not part of the current release. Keep the objects in AIStor and bring the structured data and its embeddings into HeliosDB Full.

Step 1: Keep Objects Where They Are

Files, model checkpoints and backups stay in AIStor; your applications keep their S3 endpoint.

Step 2: Load the Data You Query into Tables

import boto3, csv, io, psycopg2

s3 = boto3.client('s3', endpoint_url='http://aistor-cluster:9000')
conn = psycopg2.connect("host=heliosdb port=5432 dbname=helios")
cur = conn.cursor()

# Read a CSV object from AIStor and load its rows over the PostgreSQL wire
body = s3.get_object(Bucket='data-lake', Key='orders/2026-01.csv')['Body'].read()
for row in csv.DictReader(io.StringIO(body.decode('utf-8'))):
    cur.execute(
        "INSERT INTO orders (order_id, customer_id, total) VALUES (%s, %s, %s)",
        (row['order_id'], row['customer_id'], row['total']),
    )
conn.commit()

Step 3: Add Vector Search Next to the Data

In HeliosDB Full, embeddings live in vector stores on the HTTP gateway (default port 8443), on the same server as the tables. Add each row's text with its primary key in the metadata, search the store, then read the matching rows over the PostgreSQL wire. Start the server with HELIOSDB_API_KEY set; every gateway route except the health probes requires it, sent as X-API-Key or Authorization: Bearer.

# Create a store (the dimension is taken from the first embedding)
curl -s -X POST http://heliosdb:8443/api/v1/vectors/stores \
  -H "X-API-Key: $HELIOSDB_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"name": "documents"}'

# Add texts; the gateway embeds them with the configured provider
curl -s -X POST http://heliosdb:8443/api/v1/vectors/stores/documents/texts \
  -H "X-API-Key: $HELIOSDB_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"texts": [{"id": "doc-42", "text": "Q3 budget review ...", "metadata": {"row_id": 42, "department": "finance"}}]}'

# Hybrid search: BM25 and cosine scores fused; each hit returns id, text, score and metadata
curl -s -X POST http://heliosdb:8443/api/v1/vectors/stores/documents/search/hybrid \
  -H "X-API-Key: $HELIOSDB_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"query": "budget overruns", "top_k": 10, "bm25_weight": 0.5, "cosine_weight": 0.5}'

Vector columns, HNSW indexes and distance operators in SQL are planned for HeliosDB Full.

---

Summary

MinIO AIStor is excellent infrastructure for teams that already have a mature AI/ML platform and need a fast S3 backend. HeliosDB Full is for teams that want SQL tables and vector retrieval served by one licensed server, with in-database ML on the roadmap. HeliosDB Full works alongside AIStor as the query and AI layer for the data you load into it; an S3-compatible object API for HeliosDB Full is on the roadmap, so it does not replace AIStor today.