useful-notes/hqew/012-query-engines-for-non-sql-databases.md

81 lines
1.8 KiB
Markdown
Raw Normal View History

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