The query contains only literal values and no bind markers…

Error message

The query contains only literal values and no bind markers. Using one or more '?' placeholder values (bind markers) allows a prepared statement to be reused. Query executed on keyspace '<keyspace>', table '<table>'.

What it means

PreparedStatementParameterRequirementGuardrail.guard fires when a query executed through the prepared-statement path contains only literal values and no bind markers. Cassandra warns (or fails, if configured) because a prepared statement without placeholders provides no reuse benefit and can cause unbounded prepared-statement cache growth and server-side prepared statement churn.

Solutions

Rewrite the query to use '?' bind markers and supply values via the bound-statement API.
Prepare the statement once and reuse it with different bound values.
If literals are intentional and rare, adjust or disable the prepare_parameters guardrail thresholds in cassandra.yaml.

Example fix

// before
PreparedStatement ps = session.prepare("SELECT * FROM users WHERE id = 5");
// after
PreparedStatement ps = session.prepare("SELECT * FROM users WHERE id = ?");
session.execute(ps.bind(5));

Defensive patterns

Strategy: validation

Validate before calling

// Check a CQL string has bind markers before preparing
if (!query.contains("?")) {
    throw new IllegalArgumentException("Query must use bind markers: " + query);
}

Prevention

Always use '?' placeholders with bound values instead of string interpolation.
Enable this guardrail in dev/staging to catch offenders early.
Reuse a cache of prepared statements instead of preparing per request.

When it happens

Trigger: Driver code calling session.prepare("SELECT ... WHERE id = 5") with literals instead of '?' placeholders, then executing it; ORMs or query builders interpolating values before preparing; executing many distinct literal-only prepared statements on keyspace/table <keyspace>.<table>.

Common situations: Application frameworks generating queries with string interpolation; developers misunderstanding prepare() and preparing per-value statements; prepared-station cache pressure alarms leading to this guardrail being enabled.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/b6c4dc0f202bbe6a. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/db/guardrails/PreparedStatementParameterRequirementGuardrail.java:63

                && !restrictions.hasClusteringColumnsRestrictions()
                && !restrictions.hasNonPrimaryKeyRestrictions()))
            return;

        if (!enabled(state))
            return;

        final GuardrailsConfig config = Guardrails.CONFIG_PROVIDER.getOrCreate(state);

        boolean failOn = config.getPreparedStatementsRequireParametersEnabled();
        if (!failOn && !config.getPreparedStatementsRequireParametersWarned())
            return;

        final String message = MISPREPARED_STATEMENT_MESSAGE + " Query executed on keyspace '" + keyspace + "', table '" + table + "'.";

        if (failOn)
            fail(message, state);
        else
            warn(message);
    }
}

View on GitHub (pinned to 88fd0f6a0e)