OOM Regression Bug in Neptune v1.4.8.0

Question

I have also opened a support case, but putting it here for reference for others.

After upgrading to Neptune engine version 1.4.8.0, queries utilizing grouped property path alternations with arbitrary-length operators (p1|p2|p3)* trigger Out Of Memory (OOM) / MemoryLimitExceeded errors.

Moving the repetition operator inside the alternation—e.g., (p1*|p2*|p3*)—bypasses the OOM, but this changes the query semantics under the SPARQL 1.1 specification. This points to a query planner or engine (DFE) memory regression specifically handling path expansion across grouped alternations.

2. Environment Details

```
Engine Version: 1.4.8.0 (Regressed from version 1.4.7.0)
Instance Class: db.r8g.xlarge
Query Language: SPARQL 1.1
```

3. Minimal Reproducible Example (MRE)

Failing Query (Standard SPARQL 1.1 - OOM in 1.4.8.0):

```
PREFIX ebu:

SELECT ?entity ?type ?ancestor
WHERE {
  BIND( AS ?startNode)

# Grouped path expansion fails in memory:
  ?startNode (ebu:promotes | ebu:isEpisodeOfSeason | ebu:isSeasonOf)* ?ancestor .
  ?entity    (ebu:promotes | ebu:isEpisodeOfSeason | ebu:isSeasonOf)? ?ancestor .
  ?entity a ?type .
}
```

Forced Workaround (Succeeds, but breaks SPARQL 1.1 semantics):

```
PREFIX ebu:

SELECT ?entity ?type ?ancestor
WHERE {
  BIND( AS ?startNode)

# Moving operators inside works around OOM, but changes semantics:
  ?startNode (ebu:promotes* | ebu:isEpisodeOfSeason* | ebu:isSeasonOf*) ?ancestor .
  ?entity    (ebu:promotes? | ebu:isEpisodeOfSeason? | ebu:isSeasonOf?) ?ancestor .
  ?entity a ?type .
}
```

Dennis · Accepted Answer

As suggested by @AWS-KRL via email. There is a workaround which was to add a query hint for the joinOrder to enforce the Engine to follow the query ordering as written:

```
PREFIX hint:

WHERE {
    hint:Query hint:joinOrder "Ordered" . 
```

This fixed our queries, however, it also exposed another problem with v1.4.8.0 - only the direct parent and child are matched. Path traversal using the zeroOrMore/zeroOrOne path operator is not working for alternative paths at this moment.

Florian Turnwald · Answer

Hi Dennis,

you are  right - the automated re:Post Agent's response just reiterated your findings without offering a functional workaround.... .

Since you confirmed this exact query worked in 1.4.7.0 and now triggers an OOM in 1.4.8.0, this strongly points to a regression in how the DFE (Deep Graph Evaluation) engine plans the memory allocation for arbitrary-length grouped alternations.

Instead of changing your SPARQL semantics (which, as you noted, fundamentally alters the query logic), the most reliable, non-destructive workaround is to disable the DFE engine exclusively for this query. This forces Neptune to fall back to the alternative execution engine, bypassing the planner bug while keeping your original SPARQL 1.1 syntax intact.

I think you can do this by injecting the `useDFE` query hint:

```sparql
PREFIX hint: 
PREFIX ebu:

SELECT ?entity ?type ?ancestor
WHERE {
  hint:Query hint:useDFE false .
  
  BIND( AS ?startNode)

?startNode (ebu:promotes | ebu:isEpisodeOfSeason | ebu:isSeasonOf)* ?ancestor .
  ?entity    (ebu:promotes | ebu:isEpisodeOfSeason | ebu:isSeasonOf)? ?ancestor .
  ?entity a ?type .
}

```

**For your open support case:**
To help the AWS engineering team isolate the regression faster, I highly recommend running your original (failing) query against the `/sparql/explain` endpoint on your 1.4.8.0 instance and attaching the output to your ticket. If you still have a 1.4.7.0 instance running, attaching that explain plan for comparison will be even better.

```bash
curl -X POST --data-binary 'query=' http://:8182/sparql/explain

```

Hope this keeps your application running smoothly while support works on the patch.

re:Post Agent · Answer

Based on the symptoms you're describing, this appears to be a memory management regression in Neptune engine version 1.4.8.0 related to how the query planner handles grouped property path alternations with arbitrary-length operators. The pattern (p1|p2|p3)* should be semantically equivalent to exploring all possible paths using any combination of those predicates, but the engine appears to be consuming excessive memory during query planning or execution for this construct.

Neptune has previously addressed similar memory issues in complex query planning scenarios. Earlier releases fixed memory explosion problems when planning complex queries with property access and multiple hops with bi-directional relationships. The fact that moving the repetition operator inside the alternation—changing to (p1*|p2*|p3*)—avoids the OOM suggests the issue is specifically in how the query planner expands and evaluates the grouped alternation pattern before applying the Kleene star operator.

You're correct that these two forms are not semantically equivalent under SPARQL 1.1. The original form (p1|p2|p3)* allows arbitrary interleaving of the three predicates in any order and combination, while (p1*|p2*|p3*) only allows paths that use exclusively one predicate type at a time. This is an important distinction for your query results.

Since you've already opened a support case, that's the appropriate path forward. The AWS Support team can investigate this regression between versions 1.4.7.0 and 1.4.8.0 and work with the Neptune engineering team on a fix. In the meantime, if the semantic difference is acceptable for your use case, the workaround can serve as a temporary solution, but I understand this may not meet your requirements.

For immediate relief while awaiting a fix, you might also consider temporarily rolling back to version 1.4.7.0 if that version met your needs without this issue, though you should weigh this against any other improvements or fixes in 1.4.8.0 that you may need.  
**Sources**  
[Amazon Neptune Engine version 1.3.2.0 (2024-06-10) - Amazon Neptune](https://docs.aws.amazon.com/neptune/latest/userguide/engine-releases-1.3.2.0.html)

OOM Regression Bug in Neptune v1.4.8.0

Add your answer

Relevant content