Query across Serverless projects with ES|QL

Cross-project search (CPS) enables you to run queries across multiple linked Serverless projects from a single request.

There are several ways to control which projects a query runs against:

• Query all projects: If you just want to query across all linked projects, no special syntax is required. Queries automatically run against the origin and all linked projects by default.
• Use project routing: Use project routing to limit the scope of your search to specific projects before query execution. Excluded projects are not queried.
• Use index expressions: Use index expressions for fine-grained control over which projects and indices are queried, by qualifying index names with a project alias. Search expressions can be used independently or combined with project routing.

This page covers ES|QL-specific CPS behavior. Before continuing, make sure you are familiar with the following:

• Cross-project search
• Linked projects
• How search works in CPS
• Project routing in CPS
• Tags in CPS

The default behavior is to query across the origin project and all linked projects automatically. The following example queries the data index and includes the _index metadata field to identify which project each result came from:

				GET /_query
					{
  "query": "FROM data METADATA _index",
  "include_execution_metadata": true
}
		

1. METADATA _index returns the fully-qualified index name for each document. Documents from linked projects include the project alias prefix, for example linked-project-1:data.
2. Required to include the _clusters object in the response. Defaults to false.

The response includes:

• a _clusters object showing the status of each participating project
• a values array where each row includes the qualified index name identifying which project the document came from

{
  "took": 329,
  "is_partial": false,
  "columns": [
    { "name": "_index", "type": "keyword" }
  ],
  "values": [
    ["data"],
    ["linked-project-1:data"]
  ],
  "_clusters": {
    "total": 2,
    "successful": 2,
    "running": 0,
    "skipped": 0,
    "partial": 0,
    "failed": 0,
    "details": {
      "_origin": {
        "status": "successful",
        "indices": "data",
        "took": 328,
        "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }
      },
      "linked-project-1": {
        "status": "successful",
        "indices": "data",
        "took": 256,
        "_shards": { "total": 1, "successful": 1, "skipped": 0, "failed": 0 }
      }
    }
  }
}
		

Project routing limits the scope of a query to specific projects, based on tag values. Project routing happens before query execution, so excluded projects are never queried. This can help reduce cost and latency.

You can specify project routing in two ways:

• Embed project routing in the query with SET: This approach works wherever you can write an ES|QL query.
• Pass project routing in the _query API request body: You can pass a project_routing field to keep project routing logic separate from the query string.

SET project_routing embeds project routing directly within the ES|QL query. You can use this approach wherever you write ES|QL. SET must appear before other ES|QL commands. The semicolon after the last parameter separates it from the rest of the query. The order of parameters within SET does not matter.

SET project_routing="_alias:my-project";
FROM data
| STATS COUNT(*)
		

1. Routes the query to the project with alias my-project.

If you are constructing the full _query request, you can pass the project_routing field in the request body. This keeps project routing logic separate from the query string:

				GET /_query
					{
  "query": "FROM data | STATS COUNT(*)",
  "project_routing": "_alias:my-project"
}
		

1. Routes the query to projects whose alias matches my-project.

Both options support referencing a named project routing expression using the @ prefix. Before you can reference a named expression, you must create it using the _project_routing API. For instructions, refer to Using named project routing expressions.

				GET /_query
					{
  "query": "FROM logs | STATS COUNT(*)",
  "project_routing": "@custom-expression"
}
		

SET project_routing="@custom-expression";
FROM logs
| STATS COUNT(*)
		

ES|QL supports two types of index expressions:

• Unqualified expressions have no project prefix and search across all projects. Example: logs*.
• Qualified expressions include a project alias prefix to target a specific project or set of projects. Example: project1:logs*.

Use _origin: to target only the project from which the query is run:

FROM _origin:data
| STATS COUNT(*)
		

1. _origin always refers to the origin project, regardless of its alias.

Prefix the index name with the linked project's alias:

FROM linked-project-1:data
| STATS COUNT(*)
		

1. Replace linked-project-1 with the actual project alias.

Prefix an index expression with - to exclude it from the resolved set. The following example uses -_origin:* to exclude all indices from the origin project:

FROM data,-_origin:*
| STATS COUNT(*)
		

1. data is resolved across all projects except the origin project.

You can mix unqualified and qualified expressions in the same query:

FROM data, _origin:logs
| LIMIT 100
		

1. data is resolved across all projects. _origin:logs is resolved only in the origin project.

Use the METADATA keyword in a FROM command to include project-level information alongside query results. Project metadata fields use the _project. prefix to distinguish them from document fields.

You can use project metadata fields in two ways:

• As columns in returned result rows, to identify which project each document came from.
• In downstream commands such as WHERE, STATS, and KEEP, to filter, aggregate, or sort results by project. Note: WHERE filters results after all projects are queried and does not limit query scope.

Available fields include all predefined tags and any custom tags you have defined. You can also use wildcard patterns such as _project.my-prefix* or _project.*.

For a full list of predefined tags, refer to Tags in CPS.

Include _project._alias in METADATA to add the project alias as a column on each result row:

FROM logs* METADATA _project._alias
| KEEP @timestamp, message, _project._alias
		

1. Declaring _project._alias in METADATA makes it available in KEEP and other downstream commands.

{
  "took": 47,
  "is_partial": false,
  "columns": [
    { "name": "@timestamp", "type": "date" },
    { "name": "message", "type": "keyword" },
    { "name": "_project._alias", "type": "keyword" }
  ],
  "values": [
    ["2025-01-15T10:23:00.000Z", "connection established", "origin-project"],
    ["2025-01-15T10:24:00.000Z", "request timeout", "linked-project-1"],
    ["2025-01-15T10:25:00.000Z", "disk full", "linked-project-1"]
  ]
}
		

Include _project._alias in METADATA to group and count results by project:

FROM logs* METADATA _project._alias
| STATS doc_count = COUNT(*) BY _project._alias
		

1. _project._alias must be in METADATA to use it in STATS ... BY.

A project tag in a WHERE clause filters the result set after the query runs across all projects. It does not limit which projects are queried.

The following examples show the difference between filtering with WHERE and restricting the query scope with project routing.

FROM logs* METADATA _project._csp
| WHERE _project._csp == "aws"
		

1. Declare the tag in METADATA to use it in downstream commands.
2. All linked projects are queried. Only results from AWS projects are returned.

SET project_routing="_alias:aws-project";
FROM logs*
| STATS COUNT(*)
		

1. Only aws-project is queried. No data is fetched from other projects. For supported project routing tags, refer to Limitations.

Project routing and project metadata serve different purposes and are independent of each other. Project routing determines which projects are queried, before execution. METADATA makes tag values available in query results and downstream commands, at query time.

Using a tag in METADATA does not route the query. Using project routing does not populate METADATA fields. To both restrict queried projects and include tag values in results, specify both:

SET project_routing="_alias:*linked*";
FROM logs METADATA _project._alias
| STATS COUNT(*) BY _project._alias
		

1. Routes the query to projects whose alias matches *linked*. Only those projects are queried.
2. Declares _project._alias so it can be used in STATS. Results show a count per matched project.

Initially, project routing only supports the _alias tag. Other predefined tags (_csp, _region, and so on) and custom tags are not yet supported as project routing criteria.

ES|QL LOOKUP JOIN follows the same constraints as ES|QL cross-cluster LOOKUP JOIN. The lookup index must exist on every project being queried, because each project uses its own local copy of the lookup index data.

• ES|QL cross-cluster search: the equivalent feature for non-serverless deployments.
• FROM command: full reference for index expressions and METADATA syntax.
• SET directive: full reference for the SET directive in ES|QL.
• ES|QL metadata fields: full reference for metadata fields available in ES|QL queries.
• ES|QL LOOKUP JOIN: details on LOOKUP JOIN constraints, including cross-cluster and cross-project support.