LPQL vs SPL (Splunk query language)

Both languages read left to right: a search expression narrows the events, then each | pipe transforms the result. The mental model — filter, then shape, then aggregate, then sort/limit — is identical, which is what makes moving between them straightforward.

LPQL also shares timechart, rare, dedup, table, fields, rename and rex, and a similar eval-function set (string, math, conditional, time, pattern).

• Engine — LPQL compiles to optimised ClickHouse SQL (columnar speed, sub-200ms search); SPL runs on Splunk's proprietary engine.
• Command breadth — SPL is older and vast, with hundreds of commands and deep ecosystem apps. LPQL focuses on a curated set (around two dozen pipe commands) that cover the everyday 80–90% of analysis.
• Structured / JSON data — LPQL has first-class JSON-path navigation (a.b.c, a[k="v"].value) that maps naturally onto structured logs.
• AI generation — in LogPulse you can ask in natural language and the AI Investigator writes and runs the LPQL for you, showing the query so you can verify.
• Pricing model — the languages are free; the difference that usually drives migration is the platform economics underneath.

Because the syntax overlaps so heavily, most everyday SPL searches translate to LPQL with little or no change — the filter-pipe-aggregate skeleton is the same. The work is mostly in the long tail of SPL-specific commands and macros that have no direct equivalent, where you reshape the query to the LPQL command set. Natural-language search lowers that cost further: you can describe the result and let the AI produce the LPQL.

LPQL is the query language across LogPulse — search, detections, KPIs and MCP tools all build on it. You can write it directly, or use natural-language AI log search to generate it. See what is log management for where it fits, and the LPQL syntax reference for the full command set.