---
title: LIMIT
url: https://nexyron.tech/docs/cypher/clauses/ordering-and-paging/limit
description: Use LIMIT when the query must keep only the first N rows and the planner needs to see that operation as part of the Cypher row pipeline. Keep the clause explicit because it contr
---

# LIMIT

## Generic Description

Keep only the first N rows.

Simple example:

```cypher
MATCH (p:Person) RETURN p.name ORDER BY p.name LIMIT 10
```

## Consumer-Level Explanation

Use `LIMIT` when the query must keep only the first N rows and the planner needs to see that operation as part of the Cypher row pipeline. Keep the clause explicit because it controls row grain, variable scope, and what later clauses are allowed to reference.

## More Detailed Explanation

LIMIT is one of the most practical performance and product-shaping tools in Cypher. It turns open-ended graph exploration into bounded result sets and is especially important after ranking, recommendations, or expensive procedure output.

What this clause is really for:

-   it defines one concrete stage in the Cypher row pipeline, so variables available before and after `LIMIT` must be clear
-   it should make graph structure, temporal filters, document payload shaping, or procedure output explicit instead of relying on client-side interpretation
-   planner tooling depends on this clause boundary to know row grain, variable scope, and whether later expressions are reads, writes, schema operations, or projections

## Advanced Example

This example keeps `LIMIT` inside a complete query pipeline so the clause boundary, visible variables, and returned row shape are clear to planner tooling.

```cypher
MATCH (u:User)-[e:VIEWED]->(d:Document)
TIME e.ts BETWEEN datetime('2025-01-01T00:00:00Z') AND datetime('2025-02-01T00:00:00Z')
WITH u, d, date_trunc('day', e.ts) AS day_bucket,
     unpivot(properties(d.metadata)) AS metadata_rows,
     cosine_similarity(vector(properties(d).embedding), vector([0.22, 0.18, 0.44])) AS score
RETURN u.user_id, d.title, day_bucket, metadata_rows, score
ORDER BY day_bucket DESC, score DESC
SKIP 20
LIMIT 10
```

## Real Use Cases

-   top-k ranking
-   preview UIs
-   post-procedure result capping

## Real Limitations And Tradeoffs

-   LIMIT without meaningful ORDER BY can produce unstable user experience
-   it caps output, not necessarily upstream work unless the plan can exploit it
-   too-small limits can hide quality issues during debugging