SuiteQL or saved search: how to decide, with the governance maths

Saved searches and SuiteQL read the same data out of the same account. Choosing between them is not a question of which is better, it is a question of what the code around them is trying to do, and how much it is willing to pay in usage units.

The governance difference is the part most often missed, and it is the one that decides whether a script survives its first busy period.

The cost shape is different, not just the cost

A saved search bills per page of results. A query bills for the run. That single difference is what makes the choice size-dependent rather than a matter of preference: on a small result set they are comparable, and the gap widens with every page.

So the question to ask is not "which is cheaper" but "how many pages am I going to walk". If the answer is one, the decision does not matter much. If the answer is fifty, it is the largest line in your governance budget and nothing else you optimise will matter as much.

Where SuiteQL genuinely wins

Where saved searches still win, and it is not close

The pattern that uses both

The strongest architecture in a Map/Reduce is usually not one or the other. It is a query in getInputData that returns exactly the fields the rest of the script needs, so that map receives everything in the key value and never has to load a record or run a search of its own.

const getInputData = () => ({
  type: 'suiteql',
  query: `
    SELECT t.id, t.tranid, t.trandate, e.companyname, SUM(tl.netamount) AS total
    FROM transaction t
    JOIN transactionline tl ON tl.transaction = t.id
    JOIN entity e ON e.id = t.entity
    WHERE t.type = 'SalesOrd' AND t.trandate >= ?
    GROUP BY t.id, t.tranid, t.trandate, e.companyname
  `,
  params: [startDate],
});

That is where the governance saving actually comes from. Not the query being cheaper than the search in isolation, but the query removing the need for anything else inside the loop. The per-record cost falls to almost nothing and the script stops being the thing that fails at quarter end.

A rule of thumb

If a human being will ever look at it, build a saved search. If only code will ever read it and there is any volume involved, write a query. If it is both, a report users run and a script consumes, build the saved search for them and the query for the script, and accept the small duplication. Trying to make one artefact serve both audiences is how you end up with a saved search that nobody can modify and a script that times out.

Book a free consultation

Tell us what you are running today and where it is breaking down. Most calls run 20 to 30 minutes and end with a clear next step. We reply within one business day.