This page is the support map for the DSL Query API: for every query type, aggregation, and option, it shows how faithfully each search engine backend (Elasticsearch, Solr, Lucene) implements it. Because Viglet Turing exposes one Elasticsearch-compatible syntax over three different engines, a feature that's native on one may be translated or only partially supported on another.
Reach for this table when you're choosing a backend for a site, or when a DSL query behaves differently than you expected across engines: the badge tells you whether that's a 1:1 mapping, a translation, or a best-effort approximation. Read it alongside the query examples on the DSL Query API page.
Content AI is not in this matrix
A fourth engine, Adobe AEM Content AI, serves the DSL
API over a small, explicitly listed subset rather than a translation of the whole
syntax, so it has its own section: Adobe AEM Content
AI at the bottom of this page. The three
columns below are Elasticsearch, Solr and Lucene.
For full DSL compatibility, use Elasticsearch as the search engine backend. Solr and Lucene provide excellent coverage for the most common queries and aggregations, with best-effort translations for advanced features.
Content AI is a federated, read-only index whose query
language is Adobe's own: a filter DSL plus semantic and keyword queries, not Lucene
syntax. So rather than approximate the whole Elasticsearch surface, Turing translates
a defined subset and refuses the rest by name, with 501 Not Implemented:
Query / feature
Content AI
Notes
match_all
T
NOT exists(...) over a reserved field name: an empty filter group is invalid in Adobe's schema
match
T
A scoring fulltext query
term
T
StringFilter, NumberFilter or BooleanFilter, chosen from the value's type
terms
T
InFilter
range
T
An AND of one-sided NumberFilter / DateFilter bounds
exists
N
ExistsFilter
prefix
N
PrefixFilter
bool
P
Text clauses become the arms of a composite; the rest becomes one filter group used as their pre-filter. minimum_should_match > 1 and a must_not over a text query are refused
terms aggregation
T
termBuckets
Sorting
T
orderBy; _score is dropped, since Adobe already sorts by descending score
size
P
Capped at 50 by the API
from (offset)
N/A
Adobe paginates by opaque cursor; a non-zero from is refused rather than answered with page one
Everything else
N/A
knn, nested, geo, function_score, span, join queries, other aggregations
Why refuse rather than approximate. A clause quietly dropped because it could not be
translated would leave a query that still runs, and answers confidently from the wrong
set of documents. A 501 naming the clause is a worse response and a better answer.
This subset is what the vectorless copilot needs, which is the point: that surface
needs no embeddings, so it is the grounded-answer path that suits a federated index, and
it runs entirely through this API.