# Query Engines for Non-SQL Databases

A reference for why query engines are broader than SQL.

---

## Short answer

Yes, a query engine can be built for non-SQL databases.

SQL is only one possible query language. The broader pattern is:

- a data model exists
- users need a declarative or structured way to ask for data
- the system needs planning and execution machinery to answer those requests

So query engines are not inherently relational.

---

## What changes

What changes is the underlying algebra and operator set.

For example:

- relational engines center on tables, joins, filters, and aggregates
- graph engines center on nodes, edges, traversals, and pattern matching
- document engines center on nested objects, arrays, and field-path predicates
- rule engines center on facts, unification, recursion, and fixpoint evaluation

The architecture may still look familiar, but the internal operators differ.

---

## Examples

You can meaningfully talk about query engines for:

- document databases such as MongoDB
- search systems such as Lucene or Vespa
- vector databases such as Qdrant or Weaviate
- graph databases
- Datalog or rule engines

What makes them query engines is not SQL syntax. It is that they accept structured requests and execute them efficiently over some data model.

---

## What stays the same

Even outside SQL, many systems still have:

1. a query language or API
2. an internal representation of the request
3. optimization or rewrite steps
4. execution against indexes or stored data

So the concept generalizes cleanly beyond relational databases.

---

## Practical mental model

SQL engines optimize relational algebra.

Non-SQL engines optimize some other access model:

- graph traversal
- text retrieval
- vector similarity
- logical derivation

That is the main difference.

---

## Changelog

* **April 2, 2026** -- First version created.