What causes "Target Keyspace '%s' doesn't exist" in apache/cassandra?

Create the target keyspace first: CREATE KEYSPACE WITH replication = ...;

apache/cassandra · error · InvalidRequestException

Target Keyspace '%s' doesn't exist

Error message

Target Keyspace '%s' doesn't exist

What it means

CREATE TABLE LIKE requires an existing target keyspace. After validating the source, CopyTableStatement.apply() looks up the target keyspace and throws this InvalidRequestException when schema.getNullable(targetKeyspace) returns null. Unlike CREATE TABLE, CREATE TABLE LIKE does not implicitly create keyspaces.

Source

Thrown at src/java/org/apache/cassandra/cql3/statements/schema/CopyTableStatement.java:143

        KeyspaceMetadata sourceKeyspaceMeta = schema.getNullable(sourceKeyspace);

        if (null == sourceKeyspaceMeta)
            throw ire("Source Keyspace '%s' doesn't exist", sourceKeyspace);

        TableMetadata sourceTableMeta = sourceKeyspaceMeta.getTableOrViewNullable(sourceTableName);

        if (null == sourceTableMeta)
            throw ire("Source Table '%s.%s' doesn't exist", sourceKeyspace, sourceTableName);

        if (sourceTableMeta.isIndex())
            throw ire("Cannot use CREATE TABLE LIKE on an index table '%s.%s'.", sourceKeyspace, sourceTableName);

        if (sourceTableMeta.isView())
            throw ire("Cannot use CREATE TABLE LIKE on a materialized view '%s.%s'.", sourceKeyspace, sourceTableName);

        KeyspaceMetadata targetKeyspaceMeta = schema.getNullable(targetKeyspace);
        if (null == targetKeyspaceMeta)
            throw ire("Target Keyspace '%s' doesn't exist", targetKeyspace);

        if (targetKeyspaceMeta.hasTable(targetTableName))
        {
            if (ifNotExists)
                return schema;

            throw new AlreadyExistsException(targetKeyspace, targetTableName);
        }

        if (!sourceKeyspace.equalsIgnoreCase(targetKeyspace))
        {
            Set<String> missingUserTypes = Sets.newHashSet();
            // for different keyspace, if source table used some udts and the target table also need them
            for (ByteBuffer sourceUserTypeName : sourceTableMeta.getReferencedUserTypes())
            {
                Optional<UserType> targetUserType = targetKeyspaceMeta.types.get(sourceUserTypeName);
                Optional<UserType> sourceUserType = sourceKeyspaceMeta.types.get(sourceUserTypeName);
                if (targetUserType.isPresent() && sourceUserType.isPresent())

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Create the target keyspace first: CREATE KEYSPACE <ks> WITH replication = ...;
Correct the target keyspace name in the statement
Verify with `DESCRIBE KEYSPACES` / system_schema.keyspaces before running the copy
Provision keyspaces via migration tooling before table-copy steps

Example fix

// before
CREATE TABLE analytics.events LIKE prod.events;
-- analytics doesn't exist

// after
CREATE KEYSPACE analytics WITH replication = {'class':'NetworkTopologyStrategy','dc1':3};
CREATE TABLE analytics.events LIKE prod.events;

Defensive patterns

Strategy: validation

Validate before calling

// Ensure target keyspace exists
const rows = await session.execute(
  "SELECT keyspace_name FROM system_schema.keyspaces WHERE keyspace_name = ?", [targetKs]);
if (rows.rows.length === 0) {
  await session.execute(`CREATE KEYSPACE ${targetKs} WITH replication = {'class':'SimpleStrategy','replication_factor':1}`);
}

Type guard

null

Try / catch

try {
  session.execute(`CREATE TABLE ${targetKs}.t2 LIKE src.t1`);
} catch (e) {
  if (/Target Keyspace .* doesn't exist/.test(e.message)) {
    // create the keyspace, then retry the copy
  } else throw e;
}

Prevention

Provision target keyspaces before table-copy steps
Use idempotent CREATE KEYSPACE ... IF NOT EXISTS in bootstrap scripts
Parameterize target keyspace names per environment
Verify with system_schema.keyspaces prior to copies

When it happens

Trigger: `CREATE TABLE <targetKs>.<t> LIKE <src>` where targetKs doesn't exist on the cluster (misspelled, dropped, or not yet created).

Common situations: Running copy scripts on a fresh cluster where only the source keyspace was provisioned; typos in the target keyspace; cross-datacenter replication setups where the target keyspace was never created.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

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