while writing to buffer. Encoded response size: %d is bigger

Error message

while writing to buffer. Encoded response size: %d is bigger than threshold: %d

What it means

Dgraph caps the encoded JSON size of a single query response at maxEncodedSize (default 1MB). When toFastJSON finishes and the buffer exceeds the threshold, it refuses to return a giant response and errors instead, protecting the server and client from unbounded memory use.

Source

Thrown at query/outputnode.go:1220

	enc.fixOrder(n)

	// According to GraphQL spec response should only contain data, errors and extensions as top
	// level keys. Hence we send server_latency under extensions key.
	// https://facebook.github.io/graphql/#sec-Response-Format

	// if there is a GraphQL field that means we need to encode the response in GraphQL form,
	// otherwise encode it in DQL form.
	if field != nil {
		// if there were any GraphQL errors, we need to propagate them back to GraphQL layer along
		// with the data. So, don't return here if we get an error.
		err = sg.toGraphqlJSON(newGraphQLEncoder(ctx, enc), n, field)
	} else if err = sg.toDqlJSON(enc, n); err != nil {
		return nil, err
	}

	// Return error if encoded buffer size exceeds than a threshold size.
	if uint64(enc.buf.Len()) > maxEncodedSize {
		return nil, fmt.Errorf("while writing to buffer. Encoded response size: %d"+
			" is bigger than threshold: %d", enc.buf.Len(), maxEncodedSize)
	}

	return enc.buf.Bytes(), err
}

func (sg *SubGraph) toDqlJSON(enc *encoder, n fastJsonNode) error {
	if enc.children(n) == nil {
		x.Check2(enc.buf.WriteString(`{}`))
		return nil
	}
	return enc.encode(n)
}

func (sg *SubGraph) toGraphqlJSON(genc *graphQLEncoder, n fastJsonNode, f gqlSchema.Field) error {
	// GraphQL queries will always have at least one query whose results are visible to users,
	// implying that the root fastJson node will always have at least one child. So, no need
	// to check for the case where there are no children for the root fastJson node.

View on GitHub (pinned to 759e242be6)

Solutions

Raise the encoded size limit: --limit "encoded-size=<bytes>" (or LIMIT option encoded-size) on the server and/or per-query via the limit directive
Paginate: add first/offset or paginate roots and fetch in batches
Avoid expand(_all_)/deep recurse; project only needed predicates
Reduce fan-out with @filter on nested edges

Example fix

# before (server flags)
dgraph alpha --limit "query-edge=1000000"
# after
dgraph alpha --limit "query-edge=1000000;encoded-size=10485760"

Defensive patterns

Strategy: try-catch

Validate before calling

const [{ count }] = await dgraph.query('{ c(func: type(Person)) { count(uid) } }');
const estBytes = count * avgNodeBytes;
if (estBytes > 1024 * 1024) throw new Error('query would exceed encoded-size; paginate');

Try / catch

try {
  return await dgraph.query(q);
} catch (e) {
  if (String(e).includes('is bigger than threshold')) {
    return await fetchInBatches(q); // retry with first/offset pagination
  }
  throw e;
}

Prevention

Set --limit "encoded-size=<bytes>" appropriate to workload
Paginate large reads instead of expand(_all_)/unbounded recurse
Project only needed predicates in queries
Use async export endpoints for full-dataset reads rather than /query

When it happens

Trigger: Any query (or ToJson call) whose encoded result exceeds the server's maxEncodedSize — e.g. deep recursion, large @normalize output, expand(_all_) on dense nodes, or many predicates per node.

Common situations: Recursive queries without depth/branch limits; expand(_all_) on wide schemas; clients on instances with default --limit "encoded-size=1mb" fetching bulk exports; dot-product of reverse edges in @normalize queries.

Related errors

AI-assisted analysis of dgraph-io/dgraph@759e242be6 (2026-09-01). Data as JSON: /api/errors/21de0ba4b1d08cab. Report an issue: GitHub.