The Next Phase of Splunk Search
By Eric Levy, Senior Security Consultant
On January 15th, 2026, Splunk launched its first major update of version 10.0, 10.2. Among its several new features, it formally introduces integration of SPL2, the next iteration of Splunk’s search processing language. While SPL2 has been used under the covers for years, this is the first time it’s being offered to users from the front end.
Officially, Splunk describes it as:
SPL2 = SPL (+ optional SQL) + programming concepts
SPL2 builds on the groundwork of the original SPL by introducing a variety of new features inspired by SQL and other programming languages to increase productivity, consistency, compatibility, and overall reduce the learning chasm between end users and their ability to search data in Splunk.
SPL to SPL2: What’s Changed?
For long time Splunkers, do not fear – SPL2 maintains much of what’s familiar about regular SPL. However, there are some syntax changes, some of which we will go over here:
Plain Text Values
Consider the SPL line:
index=main “404” SPL2 no longer supports the use of standalone plain-text search values. We will need to add the search command in front of it to work:
index=main search “404” Command Syntax Changes
Consider the SPL lines:
| stats count by field-1 field-2
| bin _time span=5m SPL2 changes the syntax for listing values by requiring a comma-separated list. As such, the | stats command in SPL2 would be written as:
| stats count() by field-1, field-2 Also note the change to the count function used within the | stats command, which now always includes parentheses.
Unlike regular SPL, SPL2 now requires command options to be specified before arguments. The | bin command function should now be written as:
| bin span=5m _time Finally, thanks to the introduction of the span option to the | stats command in SPL2, we can now condense these two lines to one (once again, specifying the span before the arguments):
| stats span=5m count() by field-1, field-2 Changes to the where, eval, and from Commands
Consider the following SPL line:
| where field* = testValue OR field1 = test-Value In SPL2, use of the where, eval, and from commands require the use of double quotes around a field name or value when using any other characters than letters, numbers, or an underscore. As such:
| where “field*” = testValue OR field1 = “test-Value” Changes to concatenation
Consider the following SPL line:
| eval new-value = field1.” “.field2 SPL2 has changed the concatenation character, the period (.), to the more intuitive plus sign (+):
| eval “new-value” = field1+” “+field2 Changes to Boolean values
Consider the following SPL line:
| eval result=if(isnotnull(field1), true(), false()) In SPL2, the parentheses attached to Boolean values – true(), false(), and null() – have been removed:
| eval result=if(isnotnull(field1), true, false) SPL to SPL2: What’s New?
SQL Support!
In Splunk’s effort to make searching more accessible to end users, SPL2 now supports querying indexed data with SQL commands. Here is an example of integrated SQL usage from the Splunk Docs (note – much of the new aforementioned syntax changes to SPL2, including parentheses after count, still apply):
SELECT count(), host, _time
FROM main
WHERE sourcetype="webaccess" AND `ERROR`
GROUP BY host, span(_time, 5m)
HAVING count > 10
ORDER BY count desc
LIMIT 50
OFFSET 20 For users that don’t know SQL and would struggle acclimating to SPL2 syntax, Splunk provides two options to help users with the transition.
First is the in-search option to convert a search written with SPL to SPL2 (screenshot from Splunk Docs):
Second is Splunk’s new | spl1 command, which not only provides support for SPL queries but also SPL commands not yet supported in SPL2, such as | map or | makeresults, making the command temporarily useful for practical reasons.
The command can be explicitly called upon or done with backticks – but don’t confuse it with the use of backticks for macros, which are not supported in SPL2 at this time.
| SPL Query | SPL2 Query using backticks | SPL2 using | spl1 |
| | makeresults | $newSearch = `| makeresults` | $newSearch = | spl1 “| makeresults” |
Custom Functions
Although macros aren’t supported in SPL2, Splunk considers the ability to create custom eval functions as its closest equivalent, since it allows users to wrap SPL2 in reuseable statements.
Custom functions are one of two types:
- Generating command functions – used to create a set of events, and are invoked first in a search
- Non-generating command functions – used to process data from other generating or non-generating commands
Example syntax for a non-generating command (in this case, returning the mode of a set of integer values):
function mode_of_numbers($source, $field: int)
return | from $source
| stats count by $field
| sort – count
| head 1 Variables are defined with a preceding “$”. $source passes in the SPL2 search name to perform the custom command upon, and $field is the value to split by in the stats invocation. $field, in this case, is required to be an integer value.
Custom Data Types
By default, most data types in Splunk are “loosely typed”, which allows more flexibility in search, although SPL and SPL2 are both intuitive enough at inferring when a user defines broad data types such as integers or strings.
SPL2 allows for definition of “stronger” data types as needed. Here’s an example taken from the Splunk Docs, where id_number is a data type defined as a number between 100000 and 999999:
type id_number = int where ($value BETWEEN 100000 AND 999999) Once again, “$” is used before a variable. Types can be used in a Boolean context for validation:
| eval type_check_results = if(customer IS id_number, true, false) Remember that in SPL2, Boolean return values do not include parentheses.
SPL2 Modules
Arguably the most significant feature introduced by SPL2 are modules – files that can contain several SPL2 statements (aka searches, or anything that refers to results from data). Modules allow users to view and access results from multiple searches without the need for multiple browser tabs, and the ability to import and export statements from one module to another.
Here is an image of the interface from the Splunk Docs. One can see multiple search statements listed within the left column (search, search2, and search 3), as well as the stats output from the selected search2 in the interface’s bottom half.
There are two important things to know about leveraging search functionality with SPL2 modules:
- Indexes must be imported to make them available in your search. Splunk will do this by default when specifying indexes during UI creation of a new module, but to add any others, the syntax is as follows:
import myindex from ~indexes - All searches are referenced by name for ease of usage in other modules (and is the same principle as defining a search variable in the custom commands section). The syntax is as follows for a search referred to as “my_search”:
$my_search = index=myindex status IN (100, 200) Referring to searches by name effectively allow base searches to run within SPL2 modules, as they can be invoked in other child or parallel searches:
$my_search2 = from $my_search search category IN (“handshake”, “encrypt”) | stats count by status Items from an SPL2 module – searches, functions, or data types – can be exported as SPL2 views and shared with other users, which can then be imported into other SPL2 modules.
These are just a small selection of features introduced in Splunk’s next evolution of search, SPL2. Others include JSON specific and Lambda functions (which allow passing functions as an argument into other functions) for improved JSON normalization, robust access control, and masking data at search time – an simplified evolution of the concept Zubair Rauf and I wrote about to do this at index time.
For more information and updates to features and availability, be sure to refer to the latest Splunk Docs on SPL2. Happy Splunking!
About the Author
Eric Levy is a Splunk Core Certified Consultant who joined the TekStream team in July 2022. Eric’s background and eagerness to learn makes him excited to unlock the data possibilities Splunk has to offer its clients. Eric’s portfolio of projects makes him well adapted to time management and a diverse array of technical situations and has since expanded his horizons into Enterprise Security engagements as well as a full-time member of the IRS Splunk team.
Eric resides in Arlington, Virginia and is a proud Virginia Tech graduate. In his free time, he continues to pursue his love of music.