HeliosDB vs MongoDB

Keep MongoDB when your application reads and writes through MongoDB drivers: HeliosDB Full's MongoDB listener accepts and authenticates those connections, but reading and writing documents through it is planned. Choose HeliosDB Full when you are ready to move documents into JSONB columns and query them over the PostgreSQL, MySQL or Oracle wire protocol, with HTTP vector stores in the same licensed engine; time travel, branching and SQL vector indexes for HeliosDB Full are planned.

MongoDB pioneered the document database, and its 2018 relicensing to SSPL sent part of the ecosystem looking for alternatives: AWS built DocumentDB and FerretDB built a protocol translator. HeliosDB Full is a SQL engine with an opt-in MongoDB wire listener. Today that listener completes the handshake and SCRAM-SHA-256 authentication; reading and writing HeliosDB tables through it is planned, and so are GridFS and capped collections (compatibility notes). What works today is the SQL path: store documents as JSONB rows and query them from PostgreSQL, MySQL or Oracle clients. HeliosDB Full is itself source-available under SSPL-1.0 and distributed to licensed customers, so it is not a way to leave SSPL behind.

---

Quick Comparison

---

How does HeliosDB Full differ from FerretDB?

FerretDB translates the MongoDB wire protocol into SQL on PostgreSQL or SQLite. HeliosDB Full builds a MongoDB listener into its own engine, next to its HTTP vector stores and its PostgreSQL, MySQL and Oracle listeners, but that listener currently stops at the handshake and authentication: reading and writing documents through it, aggregation pipelines, change streams, GridFS and capped collections are planned (compatibility notes). If you are moving the data into SQL anyway, HeliosDB Full serves it over the PostgreSQL, MySQL and Oracle listeners and keeps embeddings in HTTP vector stores; SQL vector indexes, time travel and branching for HeliosDB Full are planned.

FerretDB Architecture:
+------------------+     +------------------+
| MongoDB Client   |---->|    FerretDB      |---> PostgreSQL / SQLite
| (mongosh, etc.)  |     | (protocol proxy) |     (external dependency)
+------------------+     +------------------+


HeliosDB Full Architecture (today):
+------------------+     +---------------------------------------------+
| MongoDB Client   |---->|              HeliosDB Full                   |
| (mongosh, etc.)  |     |                                             |
+------------------+     |  MongoDB listener (opt-in)                   |
                         |    Handshake + SCRAM-SHA-256 auth            |
                         |    Document reads and writes: planned        |
+------------------+     |                                             |
| SQL Client       |---->|  PostgreSQL / MySQL / Oracle listeners       |
| (psql, JDBC ...) |     |    Read and write the shared tables          |
+------------------+     |                                             |
                         |  SQL Core Engine                             |
                         |    JSONB documents in tables                 |
                         |    HTTP vector stores (HNSW, hybrid search)  |
                         |    MVCC + ACID transactions                  |
                         |    LSM storage (no external DB)              |
                         +---------------------------------------------+

---

Where do HeliosDB Full's AI features run?

On the HTTP gateway: HeliosDB Full serves vector stores with hybrid search, embeddings, chat completions and agent memory there; SQL vector indexes with Product Quantization, NL-to-SQL and in-database model training are planned. Their MongoDB-protocol forms, such as $vectorSearch inside an aggregation pipeline, depend on document reads through the MongoDB listener, which are planned too. Load documents over SQL and keep their embeddings in a vector store (compatibility notes).

Vector Search

MongoDB Atlas offers vector search in the cloud, through Atlas Search. HeliosDB Full serves self-hosted HNSW vector stores with hybrid search over its HTTP gateway (POST /api/v1/vectors/stores/{store}/search/hybrid); vector search in SQL and through $vectorSearch on the MongoDB listener are planned.

// MongoDB Atlas: $vectorSearch (cloud-only, requires Atlas)
db.products.aggregate([
    {
        $vectorSearch: {
            index: "vector_index",
            path: "embedding",
            queryVector: [0.12, -0.45, 0.89, /* ... */],
            numCandidates: 100,
            limit: 10
        }
    },
    { $project: { name: 1, score: { $meta: "vectorSearchScore" } } }
]);

---

Can HeliosDB Full run MongoDB aggregation pipelines?

Not through the MongoDB listener yet. The compatibility matrix lists 30+ stages, including $lookup, $graphLookup, $facet, $bucket, $setWindowFields, $densify, $fill and $unionWith (compatibility matrix), but the listener does not read or write tables yet, so pipelines through it are planned. Today, write the pipeline as SQL over the PostgreSQL wire; the common stages map directly:

---

Code Examples

Connecting with mongosh

# The listener is opt-in (start HeliosDB Full with --enable-mongodb)
# and accepts SCRAM-SHA-256 only (SCRAM-SHA-1 is refused)
mongosh "mongodb://admin:password@heliosdb-host:27017/mydb?authMechanism=SCRAM-SHA-256"

# The connection authenticates; reading and writing documents through
# the listener is planned, so load and query the data over SQL (below)

Documents as JSONB, Queried over PostgreSQL

-- psql -h heliosdb-host -p 5432 -d mydb
CREATE TABLE users (
    id  TEXT PRIMARY KEY,
    doc JSONB NOT NULL
);

INSERT INTO users (id, doc) VALUES
    ('u1', '{"name": "Alice", "age": 30, "dept": "Engineering", "tags": ["admin", "dev"]}'),
    ('u2', '{"name": "Bob", "age": 25, "dept": "Marketing", "tags": ["viewer"]}'),
    ('u3', '{"name": "Carol", "age": 35, "dept": "Engineering", "tags": ["admin"]}');

-- MongoDB: db.users.find({ dept: "Engineering" }).sort({ age: -1 })
SELECT doc->>'name' AS name, (doc->>'age')::int AS age
FROM users
WHERE doc @> '{"dept": "Engineering"}'
ORDER BY age DESC;

An Aggregation Pipeline, Rewritten as SQL

// MongoDB: multi-stage pipeline with $facet
db.orders.aggregate([
    { $match: { date: { $gte: ISODate("2026-01-01") } } },
    {
        $facet: {
            byDepartment: [
                { $group: { _id: "$department", revenue: { $sum: "$total" } } },
                { $sort: { revenue: -1 } }
            ],
            topCustomers: [
                { $group: { _id: "$customer_id", spent: { $sum: "$total" } } },
                { $sort: { spent: -1 } },
                { $limit: 10 },
                { $lookup: {
                    from: "customers",
                    localField: "_id",
                    foreignField: "_id",
                    as: "customer"
                }},
                { $unwind: "$customer" },
                { $project: { name: "$customer.name", spent: 1 } }
            ]
        }
    }
]);

-- HeliosDB Full: one query per facet, over the PostgreSQL wire

-- byDepartment
SELECT doc->>'department' AS department,
       SUM((doc->>'total')::numeric) AS revenue
FROM orders
WHERE (doc->>'date')::timestamptz >= '2026-01-01'
GROUP BY 1
ORDER BY revenue DESC;

-- topCustomers: $group + $lookup + $unwind become GROUP BY + JOIN
SELECT c.doc->>'name' AS name, t.spent
FROM (
    SELECT doc->>'customer_id' AS customer_id,
           SUM((doc->>'total')::numeric) AS spent
    FROM orders
    WHERE (doc->>'date')::timestamptz >= '2026-01-01'
    GROUP BY 1
    ORDER BY spent DESC
    LIMIT 10
) t
JOIN customers c ON c.id = t.customer_id
ORDER BY t.spent DESC;

Vector Search (RAG Retrieval)

Keep the documents in tables and their embeddings in an HTTP vector store, then retrieve with POST /api/v1/vectors/stores/{store}/search/hybrid. Vector columns and HNSW indexes in SQL are planned for HeliosDB Full.

Transactions

MongoDB session transactions through the listener are planned with its reads and writes. In SQL, one multi-statement transaction covers the same transfer:

BEGIN;
UPDATE accounts SET balance = balance - 500 WHERE name = 'Alice';
UPDATE accounts SET balance = balance + 500 WHERE name = 'Bob';
INSERT INTO transfers (from_name, to_name, amount, created_at)
VALUES ('Alice', 'Bob', 500, NOW());
COMMIT;

---

When to Choose Each

Choose MongoDB When

• Your application talks to the database through MongoDB drivers --- HeliosDB Full's listener authenticates driver connections, but reading and writing documents through it, aggregation pipelines, change streams, GridFS and capped collections are planned.
• Mature ecosystem matters most --- MongoDB has 15+ years of drivers, tools, tutorials, and community. If your team knows MongoDB deeply and needs the broadest third-party integration, MongoDB is the safe bet.
• MongoDB Atlas is acceptable --- If you are already on Atlas and comfortable with the pricing and vendor relationship, Atlas provides a polished managed experience with built-in monitoring, backups, and Atlas Search.
• Sharded cluster at massive scale --- MongoDB's sharding implementation (config servers + mongos) has run at multi-terabyte scale in production for years.
• Client-side field-level encryption --- If you need CSFLE with automatic encryption/decryption in the driver, MongoDB has this today.

Choose HeliosDB When

• AI/RAG is a core requirement --- HeliosDB Full serves vector stores with hybrid search, embeddings and agent memory over its HTTP gateway, self-hosted; NL-to-SQL, intelligent indexing and anomaly detection are planned.
• Self-hosted vector search --- MongoDB vector search requires Atlas (cloud-only). HeliosDB Full runs HNSW vector stores on your own infrastructure, behind its HTTP gateway.
• You are moving documents into SQL --- Store them as JSONB rows and query them with joins, window functions and CTEs from PostgreSQL, MySQL or Oracle clients; a data scientist uses psql while the application uses a PostgreSQL driver.
• Annual licensing --- HeliosDB Full is custom-priced on an annual contract (see pricing) rather than metered by usage.

---

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).

• Your application reads or writes through MongoDB drivers. The MongoDB listener accepts connections and SCRAM-SHA-256 authentication; reading and writing HeliosDB tables through it is planned. Compatibility notes
• You use GridFS, capped collections, server-side JavaScript or map-reduce. GridFS and capped collections are not supported and are planned; server-side JavaScript and map-reduce are not supported. MongoDB compatibility matrix
• Your drivers default to SCRAM-SHA-1. The listener accepts SCRAM-SHA-256 only; set authMechanism=SCRAM-SHA-256. The listener is also opt-in (--enable-mongodb). Compatibility notes
• 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 a permissive or free licence. MongoDB wire compatibility is a HeliosDB Full feature, and Full is SSPL-1.0 under an annual commercial license. Full FAQ: licensing · Pricing
• You depend on MongoDB storage behaviour. Documents become JSONB rows and MongoDB indexes become HeliosDB index types, so query plans and edge cases differ. Behavioral differences

---

Migration Path

Moving from MongoDB to HeliosDB Full today is a move to SQL: export the collections, load them as JSONB rows over the PostgreSQL wire protocol, then rewrite driver calls as SQL. The MongoDB migration guide covers schema choices and import scripts. Pointing MongoDB drivers at the HeliosDB listener becomes an option once its reads and writes ship (compatibility notes).

Step 1: Export from MongoDB

# Export each collection as a JSON array
mongoexport --uri="mongodb://mongodb-host:27017/mydb" \
  --collection=users --out=users.json --jsonArray

Step 2: Load the Documents as JSONB over the PostgreSQL Wire

import json
import psycopg2

conn = psycopg2.connect("host=heliosdb-host port=5432 dbname=mydb user=app")
cur = conn.cursor()
cur.execute("""
    CREATE TABLE IF NOT EXISTS users (
        mongo_id TEXT PRIMARY KEY,
        doc      JSONB NOT NULL
    )
""")

with open("users.json", encoding="utf-8") as f:
    for doc in json.load(f):
        raw_id = doc.pop("_id")
        mongo_id = raw_id.get("$oid", "") if isinstance(raw_id, dict) else str(raw_id)
        cur.execute(
            "INSERT INTO users (mongo_id, doc) VALUES (%s, %s::jsonb)",
            (mongo_id, json.dumps(doc)),
        )

conn.commit()

Step 3: Verify Against the Source

-- Compare with db.users.countDocuments() on MongoDB
SELECT COUNT(*) FROM users;

-- Compare with db.users.aggregate([{ $group: { _id: "$status", count: { $sum: 1 } } }])
SELECT doc->>'status' AS status, COUNT(*)
FROM users
GROUP BY 1;

Step 4: Rewrite Driver Calls as SQL, Then Add Vector Search (Optional)

Replace find, insert, update and aggregate calls with SQL through a PostgreSQL driver, using the stage mapping above. For vector search, keep embeddings in an HTTP vector store and query it with POST /api/v1/vectors/stores/{store}/search/hybrid; vector indexes in SQL are planned for HeliosDB Full.

---

Pricing Comparison

---

Summary

MongoDB defined the document database category, and FerretDB offers an Apache-2.0 translation layer over PostgreSQL or SQLite. HeliosDB Full makes a different trade: one SSPL-1.0 licensed engine where documents live as JSONB rows next to HTTP vector stores, queried over the PostgreSQL, MySQL or Oracle wire protocol; time travel, branching and SQL vector indexes for HeliosDB Full are planned. Its MongoDB listener authenticates drivers today; reading and writing documents through it is planned, so check the compatibility notes before you plan a cutover that keeps MongoDB drivers.