MindsDB

Last reviewed Sep 13, 2026 · 828 words

CREATE MODEL churn_predictor
FROM shop (SELECT * FROM customers)
PREDICT churned;

SELECT email, churned, churned_confidence
FROM churn_predictor
WHERE signup_source = 'organic';

That is the MindsDB pitch in 6 lines: connect a database, point a model at a table, and query predictions as if they were columns. It works, and it has expanded since to cover LLMs, knowledge bases for retrieval, and agents that answer questions across several connected sources, all through the same SQL surface, plus an MCP server so a coding assistant can query your data through it. The honest assessment for a self-hoster is that it is a large platform with a hundred-plus integrations, designed for teams whose data lives in many places, and that a homelab with one Postgres and an Ollama instance usually needs about a tenth of it.

What the SQL abstraction buys you

Three things, in decreasing order of how often I see them used. Federated queries: CREATE DATABASE connects Postgres, MySQL, MongoDB, Google Sheets, Slack, GitHub, an S3 bucket, and you join across them in one statement. Knowledge bases: CREATE KNOWLEDGE_BASE with an embedding model, then INSERT INTO it from any of those sources, and SELECT ... WHERE content = 'question' does semantic retrieval with the vector store handled for you. Agents: CREATE AGENT binds an LLM to a set of tables and knowledge bases and you ask it questions in SQL. Scheduled jobs run any of this on a timer. If your organisation's data is scattered and the people who need it speak SQL, this is a coherent story that would otherwise take a pipeline, a vector database and a chat app to assemble.

Running it: one container, two ports, real memory

docker run -d --name mindsdb \
  -p 47334:47334 -p 47335:47335 \
  -v ./mindsdb:/root/mdb_storage \
  mindsdb/mindsdb

Port 47334 serves the web editor and HTTP API; 47335 speaks the MySQL wire protocol, so any SQL client, Grafana or a BI tool can connect as if MindsDB were a MySQL server. The catalogue's 512 MB is the floor for the shell; every integration pulls its own client libraries, embedding runs locally by default, and 2 to 4 GB is realistic once you have a knowledge base of any size. The catalogue's "resource hungry" con is fair. Give it its own VM or a memory limit and let it be killed rather than taking Postgres with it.

Models plug in through engines: CREATE ML_ENGINE ollama_engine FROM ollama USING ollama_serve_url = 'http://ollama:11434' points it at your local Ollama, and OpenAI, Anthropic and the rest are the same statement with an API key. Your data never leaves the box if you keep the engine local, which is the main reason to self-host this rather than use the cloud offering.

The licence is Elastic-2.0, and that is fine for you

Elastic-2.0 forbids offering MindsDB as a managed service to third parties and stripping licence protections. Running it inside your company, on your homelab, or embedded behind your own application is fine. The short version is that unless you plan to sell "MindsDB hosting", you can ignore it.

What it is not, and the simpler stacks

It is not a vector database; it manages one for you (embedded by default, or point it at Qdrant and others). It is not a chat UI; agents are answered through SQL and an API, and you bring the front end. It is not a training platform in the deep-learning sense; the classical models are AutoML over tabular data, competent and not tunable at research depth. For a self-hoster with one database who wants "ask questions about my data", n8n calling Ollama with a Postgres node covers it in an afternoon and idles at 200 MB. For retrieval over documents, a dedicated RAG app is friendlier. The vector database guide lays out that part of the stack on its own terms. The AI category has the rest.

Where it belongs in a stack

Between many data sources and the people or agents who need to query them, in an organisation, run by someone who owns data infrastructure. The pattern that works: MindsDB on its own 4 GB VM, connected to read replicas rather than primaries, Ollama on a GPU box as the engine, knowledge bases refreshed by scheduled jobs overnight, and the MySQL port exposed to the BI tool and the internal agents. The pattern that does not: installing it on a homelab to "add AI" to one database and discovering a 3 GB service for what a single Python script does.

What I'd do

Company with 5 or more data sources and SQL-literate staff: run it, local engines only, on a dedicated VM, and treat the SQL surface as the product. Homelab or solo developer: skip it, run Ollama and n8n, and come back when you have the federation problem it exists to solve.