LATEST

Generic Description

Keep the newest row per logical series key.

Simple example:

MATCH (r:Reading) LATEST ON r.ts BY r.sensor_id RETURN r

Consumer-Level Explanation

Use LATEST when the query must keep the newest row per logical series key 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

LATEST is a convenience clause for an extremely common pattern: newest-known state per entity or series. Instead of forcing every query author to rebuild that logic manually, it gives the pattern first-class expression.

What this clause is really for:

• it defines one concrete stage in the Cypher row pipeline, so variables available before and after LATEST 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 LATEST inside a complete query pipeline so the clause boundary, visible variables, and returned row shape are clear to planner tooling.

MATCH (s:Sensor)-[r:EMITS]->(m:Measurement)
TIME r.ts BETWEEN datetime('2025-01-01T00:00:00Z') AND datetime('2025-01-07T00:00:00Z')
WITH s, r, m, date_trunc('hour', r.ts) AS bucket, properties(m) AS payload
RETURN s.sensor_id, bucket, keys(payload) AS payload_keys, unpivot(payload) AS metrics
ORDER BY bucket DESC

Real Use Cases

• latest sensor reading per device
• current status per user or account
• latest operational metric per service and dimension

Real Limitations And Tradeoffs

• the grouping keys define the meaning of “latest”, so poor key design gives wrong answers
• if multiple rows tie on timestamp, you still need to understand the resulting semantics
• best thought of as a query convenience over a properly modeled event/history table