MindsDB Query Engine

Quick Verdict

MindsDB Query Engine is for engineering teams that want a self-hosted data access layer for AI agents, BI clients, or internal applications. It is neither a conventional transactional database nor a hosted natural-language-to-SQL assistant. Connected data generally stays in its source system while the engine translates and pushes down queries, combines results across sources, and streams rows back through a unified SQL surface. Selected unstructured content can instead be chunked, embedded, and indexed in a Knowledge Base for semantic, keyword, and metadata-filtered retrieval.

The 2026 product boundary matters. MindsDB Query Engine remains a separately maintained, self-hosted project in the official mindsdb/engine repository. MindsHub is another product from the same team: a hosted agent workspace with model routing, a credential vault, persistent execution, and packaged agent experiences. Official documentation says MindsHub is not built on top of Query Engine. Features and prices from MindsHub therefore must not be attributed to the engine.

The engine can be downloaded without a subscription, but its core is under Elastic License 2.0 rather than an OSI-approved open-source license. The integrations directory carries MIT licensing according to the project’s license structure. ELv2 permits many internal and commercial uses but restricts offering substantial product functionality to third parties as a hosted or managed service. Legal review is appropriate before redistribution or service-provider use.

Best For

• Data platform teams that need a self-hosted SQL layer over databases, warehouses, SaaS applications, files, and vector infrastructure.
• AI application developers who want an agent to use fewer, more consistent data tools instead of one bespoke API tool per source.
• RAG teams combining semantic retrieval, BM25 keyword matching, and SQL metadata filters through one query interface.
• Organizations that already operate secret management, database roles, audit logging, observability, and incident response.
• BI or application teams that can use MySQL- or PostgreSQL-compatible client protocols to reach a federated layer.

It is a poor fit for a business user seeking a zero-configuration hosted chatbot. It is also not a substitute for a transaction store, data warehouse, credential vault, model router, or complete agent approval interface.

Key Features

• Federated SQL: Connects many databases, warehouses, applications, and files behind one SQL dialect while pushing work toward the source where possible.
• Multiple client interfaces: Provides an HTTP editor plus MySQL- and PostgreSQL-compatible protocols for SQL clients, ORMs, and BI tools.
• Cross-source views and joins: Combines data from distinct systems, subject to each source’s semantics, latency, rate limits, and consistency model.
• Knowledge Bases: Chunks and embeds selected content into vector storage, then supports vector similarity, BM25 keyword search, and metadata filters.
• Jobs and triggers: Runs SQL on a schedule or in response to supported data changes, which can refresh indexes and derived data. Retry behavior and idempotency still need operational design.
• Projects and views: Namespaces objects and saves reusable transformations for applications and agents.
• Data layer boundary: Can be exposed to an agent through SQL or MCP, but it does not become a full agent runtime, model router, credential vault, or human approval system.

Use Cases

One realistic pattern is to connect a customer database, a support-ticket system, and product documentation under one logical project. An agent can read a customer status through a restricted source account, retrieve the applicable policy passage from a Knowledge Base, and combine the evidence in one workflow. Another pattern is exposing curated cross-source views to an existing SQL client so each consumer does not need to learn several vendor APIs.

Federation does not make data movement and performance concerns disappear. Large joins may pull substantial intermediate results across a network; a SaaS connector may impose rate limits; and two sources may not represent the same point in time. Test pushdown, result cardinality, timeout behavior, failure recovery, and freshness with representative workloads. A carefully modeled warehouse may remain the better choice for predictable high-volume analytics.

Every source should use a separate least-privilege credential, isolated by project and environment. Expose only the schema, views, and columns required for the task, then validate against an isolated test database or masked replica. Production connections should be read-only by default, and an agent should call restricted tools without receiving raw secrets. Require explicit confirmation for risky queries, commands, or writes. Before execution, require human SQL and query-plan review covering join scope and expected cardinality, with timeouts, row limits, transaction boundaries, and tested backups. Log the caller, query or tool, result size, duration, and error state, but redact credentials and sensitive result bodies. Define retention and deletion for both logs and Knowledge Base indexes.

The data path also changes by feature. Federated queries normally read data in place, but their results pass through the engine and potentially an agent or model. Knowledge Bases deliberately copy selected content into chunks, embeddings, metadata, and vector storage. Map both paths and review the embedding provider, storage location, and deletion mechanism before indexing regulated information.

Pricing

MindsDB Query Engine has no official subscription price for self-hosting, so this directory classifies it as free. That label applies to obtaining and running the engine, not to the complete system. Teams pay for compute, containers or hosts, source and vector databases, embedding and LLM providers, network traffic, monitoring, upgrades, backups, and engineering support.

MindsHub’s hosted Starter or Pro offers belong to a separate product and should not be used as Query Engine pricing. The license boundary is equally important: the core defaults to Elastic License 2.0, while designated integrations code uses MIT. ELv2 is source-available but not OSI-approved and restricts providing the software’s substantial functionality as a managed service to third parties. Review the license file for the exact directory and use case rather than relying on the marketing phrase “open-source.”

Pros

• Unifies structured federation and unstructured knowledge retrieval behind a familiar SQL development surface.
• Can be self-hosted within an organization’s network and use source-level database permissions.
• MySQL and PostgreSQL wire compatibility helps existing clients and BI tools connect without a bespoke SDK.
• Model-neutral Knowledge Bases allow teams to choose cloud or self-hosted embedding services.
• Jobs and triggers can keep indexes or derived views current without adding a separate scheduler for every simple task.

Cons

• The team must operate the runtime, integrations, observability, upgrades, vector storage, and model dependencies.
• ELv2 is not equivalent to MIT or Apache licensing and constrains third-party hosted-service offerings.
• Cross-source joins can be slow or inconsistent because source systems differ in capability, rate limits, and freshness.
• Knowledge Bases copy and transform selected content, so “data stays at the source” is not true for every feature.
• Current MindsDB and MindsHub material can be confused with older repositories, cloud plans, and retired product descriptions.

Alternatives

FAQ

Are MindsDB Query Engine and MindsHub the same product?

No. Query Engine is a standalone, self-hosted federated and semantic query layer. MindsHub is a separate hosted agent workspace from the same team. They may complement each other, but their features and pricing are not interchangeable.

Does MindsDB copy all connected data?

Normal federation reads live data from the source and pushes down work where possible. A Knowledge Base is different: it intentionally chunks, embeds, and indexes selected content. Query results can also flow onward to an agent or model.

Is MindsDB Query Engine open source?

The vendor calls it open-source, but the core uses Elastic License 2.0, which is not OSI-approved. The integrations directory uses MIT. ELv2 permits source access and many uses while restricting managed-service offerings of substantial functionality.

Can it replace my operational database or warehouse?

No. It is a federated query and semantic layer. It does not automatically provide transaction ownership, source data quality, dimensional modeling, backups, high availability, or predictable warehouse performance.

How should an agent access credentials and production data?

Use separate least-privilege identities for every source, project, and environment. Keep raw credentials outside the agent, make production read-only by default, confirm risky actions, and redact sensitive values from logs.

What does a free self-hosted deployment really cost?

Budget for compute, storage, vector infrastructure, embedding and LLM calls, network traffic, monitoring, upgrades, security work, and engineering support. Software acquisition is only one part of total cost.

Bottom Line

MindsDB Query Engine is a useful agent-ready data layer when a team genuinely needs federated SQL and Knowledge Bases and is prepared to operate them. Start with one representative cross-source query and one carefully scoped index. Measure correctness, pushdown, latency, source load, embedding cost, freshness, and recovery from failure. Before adoption, confirm the MindsDB-versus-MindsHub boundary, the ELv2 use restriction, least-privilege credential isolation, read-only defaults, action confirmation, model and infrastructure costs, and redacted log retention.