Do you use SuiteQL in scripts, even when you could fetch records using searches? If so, what's the reasoning behind it?

The main reason i use it, is to create complex joins in data. Searches limit you to one level of join from your base record, whereas suiteQL allows you essentially an infinite number. Anecdotally i feel as if suiteQL runs faster on large datasets too. I haven't actually tested this though or looked up anything to support that.

Another reason for using suiteQL is it can give the data in the desired format in a single line of code. Don't like the structure and how a search object behaves. And how we have to iterate over it to get the results in the desired format. With suiteql in combination with asMappedResults we can have a pretty array of objects with our desired key and value pairs. I have also created some neat functions like convert snake_case keys in the object to cameCase keys (which I personally prefer) while playing around with JSONs. And all this is done in a single line of code.

I like that camel case idea

Have created similar custom libraries to implement spacing and other things which are required in keys which are not possible while doing aliasing in suiteql.

I use SuiteQL most of the time these days as it’s less lines of code to achieve the same thing, and also because I have about 15 years of experience writing complex SQL queries so it’s faster and more intuitive for me.

have just started working with SuiteQL within the past few weeks, was a bit hesitant at first since was already familiar with saved searches and overall not very much experience with SQL. But now I am hooked on using SuiteQL, as other mentioned it's overall easier to run and nicely puts it into a JSON array.

results = query.runSuiteQL({
    query: "YOUR SUITEQL QUERY HERE"
}).asMappedResults();

also as other mentioned haven't confirmed the performance between saved searches, but overall it does seem to run faster.

with two lines of code I have an array of objects where the properties are the columns I desire. I’ve written my own wrapper for runSuiteQL().asMappedResults() that gets me all results back (even when there are more than 5000).

Apart from the many benefits mentioned above (complex joins, my long history of SQL knowledge), saved searches with multiple formulas can require special handling in code, but in SuitQL it’s not an issue. Plus saved searches are exclusively a NetSuite thing, requiring special knowledge to understand. But I can show SuiteQL to literally any developer with JS and SQL knowledge and they can read and understand it

True pain is trying to get six different columns named 'forumla(Numeric)'

perhaps last but not least, SuiteQL tends to execute faster than N/search. I see that qualitatively all the time but someone measured it, and/or I heard it from a NetSuite resource that the speedup is 10%+

Do note that sometimes you will end up using searches, so learn both as some of the stuff that is available in searches is not available in suiteql and vice versa.

qualitatively, SuiteQL seems to run much faster than a similar N/search in my experience. These days SuiteQL is my first choice for searching data in NS.

true. Document fields are not available via SuiteQL yet, which is a big annoyance for us, and we have to use a search instead

Thankyou all for sharing your insights. this is very useful.