Skip to main content
Deletion happens in two stages. A soft delete hides a schema from normal queries but keeps it readable and keeps its version number reserved. A hard delete removes it permanently and requires a prior soft delete.
Nothing restores a soft-deleted schema. Re-registering the identical schema string creates a new version—it does not revive the old one. Hard-deleted data is gone.Treat the soft delete as your window to change your mind, not as a reversible operation.

​
Soft delete

Delete a single version:
Or the whole subject:
After a soft delete the schema no longer appears in GET /subjects or GET /subjects/{subject}/versions, and consumers can no longer resolve it by subject and version.
A soft delete doesn’t remove records already on the topic, but consumers cannot resolve a soft-deleted schema through GET /schemas/ids/{id}. This differs from the Confluent Schema Registry, where GET /schemas/ids/{id} continues to return soft-deleted schemas.Plan your deletion carefully: any consumer that encounters a record whose schema was soft-deleted will fail to deserialize it.

​
Inspect deleted schemas

deleted and deletedOnly also work on GET /subjects/{subject}/versions, and deleted works on GET /schemas/ids/{id}/versions and GET /schemas/ids/{id}/subjects.

​
Hard delete

Add ?permanent=true after the soft delete:
Calling a hard delete on something that hasn’t been soft-deleted returns: Soft-deleting something twice returns 40404 for a subject or 40406 for a version.

​
References block deletion

You can’t delete a schema another schema references. The attempt returns error code 42206, for soft and hard deletes alike. Find what’s holding it:
The response is an array of schema IDs. Resolve each with GET /schemas/ids/{id}/subjects to find the subjects, and delete those first. See Schema references.

​
Version numbering after deletion

Version numbers aren’t necessarily reused after a deletion, and the exact behavior depends on how the registry is deployed for your cluster. Don’t build anything that assumes the next version will be max(version) + 1, and don’t treat a gap in version numbers as a problem. Read the version back from the registration response instead of computing it.

​
Storage

There’s no maximum number of subjects, no maximum number of versions per subject, and no storage quota, so you won’t need to delete schemas to make room. Delete them because they’re obsolete, not because you’re running out of space. The one hard limit is the 5 MB request body, which caps the size of a single schema.

​
Next steps

Manage schemas

Register schemas and set compatibility modes.

Troubleshooting

Error codes and what to do about them.