Query Engine Design Questions

A checklist note for thinking about what kind of query engine to build.

Short answer

Before building a query engine, it helps to force explicit answers to a small set of design questions.

Most architecture disagreements are really disagreements about workload, execution granularity, storage boundary, or correctness model.

Is the workload mostly transactional, analytical, streaming, search, or logical inference?
Are queries mostly point lookups, scans, aggregations, recursive rules, or top-k retrieval?

Is the data relational, document-oriented, graph-shaped, vector-based, or rule/fact based?
What is the engine's core internal representation?

Does the engine run row-at-a-time, batch-at-a-time, or over fully materialized relations?
Are blocking operators common?

Is one machine enough?
If not, where are exchange boundaries, partitioning choices, and failure handling defined?

Is the system exact, approximate, eventually consistent, ranked, or fixpoint-based?
Does it support recursion, inference, or witness generation?

These questions determine most of the major architecture choices:

If those answers are unclear, architecture discussions tend to stay vague.

This note is best used as a design checklist.

If a team can answer these questions cleanly, the likely engine shape becomes much easier to see.

If it cannot, the project is probably still mixing together several different engine ideas.