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

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.