Is there a hard limit on the size of EncodedQuery

[patrikturc]

I would like to find out when using .addEncodedQuery('Is there a char limit here?').

I am trying to limit the number of database calls by building a large encoded query and then making a single call that returns all items. Basically, instead of having a query call for each result of the previous query in a while loop, we loop through the initial result and build a large encoded query using ^NQ blocks for each of the query results. 

Let's say this results in encodedQuery of roughly 700k characters called once. Instead of making 7000 short db queries.

[Aanchal Agarwa1 · Accepted solution]

Hi 

If the encoded query is being passed via a URL (list views, GlideAjax, REST API), browsers and web servers enforce URL length limits — typically around 8,000 characters.

There is  no published char limit for Glide query but 700k characters with 7000 ^NQ blocks will almost certainly time out or fail silently. Switch to IN with chunking — same goal of reducing db calls, far more reliable at scale.

Can you share your query?

Thanks

[Its_Sagnic · Accepted solution]

Hi  @patrikturc 

For ServiceNow, there is no commonly documented hard limit specifically on GlideRecord.addEncodedQuery(), but in practice a 700,000-character encoded query is not a good approach and will likely hit platform, database limitations long before it becomes efficient.

Option 1 : Use IN instead of thousands of ^NQ

var ids = [];

while (sourceGR.next()) {
    ids.push(sourceGR.getUniqueValue());
}

var targetGR = new GlideRecord('target_table');
targetGR.addQuery('parent', 'IN', ids.join(','));
targetGR.query();

Option 2: Batch the query

var batchSize = 500;

for (var i = 0; i < ids.length; i += batchSize) {
    var batch = ids.slice(i, i + batchSize);

    var gr = new GlideRecord('target_table');
    gr.addQuery('parent', 'IN', batch.join(','));
    gr.query();

    while (gr.next()) {
        // process records
    }
}

if you find the solution helpful please mark it helpful and accept the solution.

Regards,
Sagnic

[Aanchal Agarwa1 · Accepted solution]

Hi 

If the encoded query is being passed via a URL (list views, GlideAjax, REST API), browsers and web servers enforce URL length limits — typically around 8,000 characters.

There is  no published char limit for Glide query but 700k characters with 7000 ^NQ blocks will almost certainly time out or fail silently. Switch to IN with chunking — same goal of reducing db calls, far more reliable at scale.

Can you share your query?

Thanks

[Its_Sagnic · Accepted solution]

Hi  @patrikturc 

For ServiceNow, there is no commonly documented hard limit specifically on GlideRecord.addEncodedQuery(), but in practice a 700,000-character encoded query is not a good approach and will likely hit platform, database limitations long before it becomes efficient.

Option 1 : Use IN instead of thousands of ^NQ

var ids = [];

while (sourceGR.next()) {
    ids.push(sourceGR.getUniqueValue());
}

var targetGR = new GlideRecord('target_table');
targetGR.addQuery('parent', 'IN', ids.join(','));
targetGR.query();

Option 2: Batch the query

var batchSize = 500;

for (var i = 0; i < ids.length; i += batchSize) {
    var batch = ids.slice(i, i + batchSize);

    var gr = new GlideRecord('target_table');
    gr.addQuery('parent', 'IN', batch.join(','));
    gr.query();

    while (gr.next()) {
        // process records
    }
}

if you find the solution helpful please mark it helpful and accept the solution.

Regards,
Sagnic

[abirakundu23 · Accepted solution]

Hi @patrikturc,

There is no specific a query limit mentioned in ServiceNow Documentation.

As a best practice, it's recommended to process large volumes of data in batches or chunks. This approach helps improve system performance, reduces the risk of long-running transactions, and minimizes the impact on overall platform stability.

Please follow below thread : https://www.servicenow.com/community/developer-forum/what-is-the-max-query-string-length-can-be-pass...

Please mark helpful & correct answer if it's worthy for you.

[patrikturc]

Thank you all for the very helpful answers - ServiceNow provided very similar guidance. I've now completed testing with the suggested approaches.

To my surprise, the 700k-character query completed successfully, although it took 29 seconds to run. Batching the query reduced the execution time to ~8 seconds.

After changing the logic to use IN instead, the runtime dropped further to around 2.2 seconds. Batching produced a similar runtime in this case, although it would likely be the more future-proof approach.