What is Predictive Query Language (PQL)? A Complete Guide

Every enterprise ML project follows the same pattern. A business stakeholder asks a question: "Which customers will churn next month?" A data scientist then spends 2-4 weeks building a pipeline: extracting data from multiple tables, writing joins, computing hundreds of features, selecting a model, training it, evaluating it, and deploying it. The question took 10 seconds to ask. The answer takes 10 days to build.

PQL eliminates the gap between question and answer. It is a query language that lets you describe a prediction task the same way you would describe it to a colleague: "Predict which active members will stop visiting in the next 30 days." Kumo's engine takes that description and handles everything else, from feature discovery to model training to scored output.

The headline result: SAP SALT benchmark

The SAP SALT benchmark is an enterprise-grade evaluation where real business analysts and data scientists attempt prediction tasks on SAP enterprise data. It measures how accurately different approaches predict real business outcomes on production-quality enterprise databases with multiple related tables.

KumoRFM scores 91% where PhD-level data scientists with weeks of feature engineering and hand-tuned XGBoost score 75%. The 16 percentage point gap is the value of reading relational data natively instead of flattening it into a single table.

PQL syntax: how it works

A PQL query has three parts: what to predict, who to predict for, and optionally, which entities to filter. The syntax is intentionally similar to SQL so that anyone who can write a SELECT statement can write a prediction task.

Anatomy of a PQL query

Every PQL query follows this structure:

• PREDICT — defines the target variable using an aggregation function (COUNT, SUM, AVG, MAX, MIN, LIST_DISTINCT) over a forward time window
• FOR EACH — specifies the entity to generate predictions for (e.g., each customer, each account, each article)
• WHERE (optional) — filters entities using backward time windows to focus on recently-active entities
• ASSUMING (optional) — defines a counterfactual condition for "what-if" predictions

PQL examples: 7 prediction tasks in 2-3 lines each

The following examples show real PQL queries for common enterprise prediction tasks. Each query replaces an entire ML pipeline that would otherwise require data extraction, feature engineering, model selection, and training.

1. Churn prediction

Predict which recently-active members will stop visiting in the next 30 days. The backward window (-60, 0, days) in the WHERE clause filters to members who have visited in the last 60 days, eliminating noise from already-inactive accounts.

PREDICT COUNT(VISITS.*, 0, 30, days) = 0
FOR EACH MEMBERS.MEMBER_ID
WHERE COUNT(VISITS.*, -60, 0, days) > 0

2. Fraud detection

Predict which accounts will have suspicious transaction volume exceeding $10,000 in the next 7 days. This binary classification flags accounts likely to experience high-value anomalous activity.

PREDICT SUM(TRANSACTIONS.AMOUNT, 0, 7, days) > 10000
FOR EACH ACCOUNTS.ACCOUNT_ID

3. Lead scoring

Predict which leads will convert to an order in the next 30 days. This replaces manual lead scoring models that require CRM feature engineering.

PREDICT COUNT(ORDERS.*, 0, 30, days) > 0
FOR EACH LEADS.LEAD_ID

4. Demand forecasting

Predict the total quantity sold for each article over the next 3 months. This is a regression task, not binary classification, because the target is a continuous value.

PREDICT SUM(TRANSACTIONS.QUANTITY, 0, 3, months)
FOR EACH ARTICLES.ARTICLE_ID

5. Product recommendations

Predict the top 5 products each customer is most likely to order in the next 30 days. LIST_DISTINCT returns a ranked list of distinct values, and RANK TOP N limits the output to the top candidates.

PREDICT LIST_DISTINCT(ORDERS.PRODUCT_ID, 0, 30, days)
RANK TOP 5
FOR EACH CUSTOMERS.CUSTOMER_ID

6. Customer lifetime value (LTV)

Predict the total revenue from each customer over the next 365 days. This regression task drives budget allocation for acquisition and retention spend.

PREDICT SUM(ORDERS.AMOUNT, 0, 365, days)
FOR EACH CUSTOMERS.CUSTOMER_ID

7. Counterfactual prediction (ASSUMING clause)

Predict whether a user will make a purchase in the next 4 days, assuming they receive a push notification today. The ASSUMING clause is what makes this query fundamentally different from all the others. It enables counterfactual reasoning: predicting outcomes under hypothetical interventions.

PREDICT COUNT(PURCHASES.*, 1, 4, days) > 0
FOR EACH USERS.USER_ID
ASSUMING COUNT(NOTIFICATIONS.* WHERE NOTIFICATIONS.TYPE = 'PUSH', 0, 1, days) > 0

PQL vs Python: what PQL replaces

To understand why PQL matters, you need to see what the equivalent Python pipeline looks like. A single PQL query replaces 6 distinct pipeline stages, each requiring specialized code.

PQL's backward window: eliminating noise from dead accounts

One of PQL's most powerful features is the backward time window in the WHERE clause. This filters the entity set before prediction, ensuring you only predict for entities that are relevant and actionable.

Consider the churn prediction example:

WHERE COUNT(VISITS.*, -60, 0, days) > 0

This backward window (-60, 0, days) means "only include members who had at least one visit in the last 60 days." Without this filter, your churn model would waste capacity predicting that already-inactive accounts will remain inactive, which is trivially true and operationally useless.

In traditional ML, this filtering requires a separate data preprocessing step: query the database for recently-active entities, build the feature table only for those entities, then train the model. In PQL, it is one line in the query. The engine handles the filtering automatically and ensures that the training data, features, and predictions are all scoped to the right entity set.

Supported aggregations and task types

PQL supports a range of aggregation functions, each mapping to a specific type of prediction task.

Why PQL changes who can do ML

The traditional ML pipeline requires at least three skill sets: SQL for data extraction, Python/pandas for feature engineering, and ML framework expertise for modeling. Most organizations have far more SQL-proficient analysts than ML engineers.

PQL reduces the required skill set to SQL-level knowledge. A data analyst who writes SQL queries daily can write PQL queries and produce predictions that match or exceed what a dedicated ML team builds in weeks. This is not about simplifying ML. It is about making the prediction itself the interface, rather than the pipeline.

PQL in practice: from question to prediction

A typical PQL workflow has three steps:

1. Connect your database. Point Kumo at your relational database (or data warehouse tables). Kumo reads the schema, foreign keys, and data types automatically.
2. Write the PQL query. Define what you want to predict, for which entities, with optional filters and counterfactual conditions.
3. Get scored predictions. Kumo's engine discovers features across the full relational graph, trains a model, and returns scored predictions for every entity in the query scope.

There is no feature engineering step. There is no model selection step. There is no training configuration to specify. The PQL query is the complete task specification, and the engine handles everything else.