useful-notes/scratches/query-engines-for-nonsql-databases.md

66 lines
1.9 KiB
Markdown
Raw Normal View History

# Can a Query Engine Be Built for Non-SQL Databases?
## Short answer
Yes.
A query engine is not inherently tied to SQL. SQL is just one front-end language for expressing declarative queries. The deeper idea is:
- some data model exists
- users need to ask questions over it
- the system needs a planner/executor to answer those questions
## What changes
What changes from system to system is the data model, query language, and operator set.
For example:
- a relational engine centers on tables, joins, filters, and aggregates
- a graph engine centers on nodes, edges, traversals, pattern matching, and path expansion
- a document engine centers on nested objects, array traversal, field extraction, and structural predicates
- a Datalog engine centers on facts, rules, unification, recursion, and fixpoint evaluation
## Typical examples
You can build query engines for:
- document databases
- key-value stores
- graph databases
- RDF or triple stores
- Datalog engines
- log or event stores
- custom domain-specific databases
## What stays the same
Even outside SQL, the high-level architecture is often similar:
1. parse a query language or API request
2. build an internal logical representation
3. optimize or rewrite it
4. execute it against the underlying store
The important point is that SQL is only one possible query language. A query engine is the broader idea.
## Better mental model
The right way to think about it is:
- SQL engines optimize relational algebra
- non-SQL engines optimize some other algebra or execution model
Examples include:
- graph pattern matching
- document/path navigation
- logical rule evaluation
- custom search or traversal operators
So the answer is not just "yes, but differently." It is that query engines are a general architectural pattern, and SQL is only one instance of it.
## Changelog
* **Mar 31, 2026** -- First version created.