apache/cassandra · error · InvalidRequestException

Index %s is not in the same keyspace as the queried table.

Error message

Index %s is not in the same keyspace as the queried table.

What it means

Thrown as an InvalidRequestException when a query references an index with an explicit keyspace qualifier that does not match the keyspace of the table being queried. Cassandra requires that a named index belong to the same keyspace as the table, since indexes live in the table's keyspace. This guard in IndexHints.fetchIndex prevents cross-keyspace index resolution.

Source

Thrown at src/java/org/apache/cassandra/db/filter/IndexHints.java:437

        Set<IndexMetadata> indexes = new HashSet<>(indexNames.size());

        for (QualifiedName indexName : indexNames)
        {
            IndexMetadata index = fetchIndex(indexName, table, indexRegistry);
            indexes.add(index);
        }

        return indexes;
    }

    private static IndexMetadata fetchIndex(QualifiedName indexName, TableMetadata table, IndexRegistry indexRegistry)
    {
        String name = indexName.getName();
        String keyspace = indexName.getKeyspace();

        if (keyspace != null && !table.keyspace.equals(keyspace))
            throw new InvalidRequestException(format(WRONG_KEYSPACE_ERROR, indexName));

        Index index = indexRegistry.getIndexByName(name);
        if (index == null)
            throw new InvalidRequestException(format(MISSING_INDEX_ERROR, table.name, name));

        return index.getIndexMetadata();
    }

    /**
     * Returns a comparator of index query plans based on which one has the most included indexes, so it can be used to
     * select the plans that satisfy the index hints first, and the plans that are closest to satisfy them later.
     *
     * @return a comparator of index query plans based on which one has the most included indexes
     */
    public Comparator<Index.QueryPlan> comparator()
    {
        return Comparator.comparing(plan -> Sets.intersection(included, metadata(plan.getIndexes())).size());
    }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Remove the keyspace qualifier from the index name, or qualify it with the same keyspace as the queried table
2. USE the table's keyspace and reference the index by bare name
3. Recreate the index in the keyspace of the table if it genuinely doesn't exist there

Example fix

// before
SELECT * FROM ks1.users USING INDEX ks2.users_email_idx;
// after
SELECT * FROM ks1.users USING INDEX ks1.users_email_idx;

if (indexName.getKeyspace() != null && !table.keyspace.equals(indexName.getKeyspace()))
    throw new InvalidRequestException("Index " + indexName + " is not in keyspace " + table.keyspace);

When it happens

Trigger: Executing a SELECT with a USING INDEX (or ALLOW FILTERING index hint) clause like SELECT ... USING INDEX "ks2.idx" FROM ks1.tbl where the qualified index name's keyspace differs from table.keyspace.

Common situations: Copy-pasting queries between keyspaces without updating the index qualifier; multi-keyspace environments where identical index names exist in several keyspaces; client tools that template in a default keyspace for the index name.

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

• Unknown keyspace: '" + keyspaceName + "'
• No keyspace has been specified. USE a keyspace, or explicitl
• Keyspace '${ks}' does not exist
• You have not set a keyspace for this session
• Invalid null value of timestamp

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