DETACH DATABASE

Note

Prior to using this command, the enable_bottomless engine variable must be set to ON (the default value).

Takes an unlimited storage database offline.

Refer to the Permission Matrix for the required permissions.

Syntax

DETACH DATABASE remote_database_name [AT MILESTONE "milestone_name" | FORCE | KILL]

Arguments

milestone_name

A quoted string that specifies the milestone from which to detach the database.

FORCE

The FORCE argument allows you to terminate ongoing uploads to remote storage and forcibly detach the database. This can be useful in situations where, for example, the detach process is unable to upload blobs to remote storage or encounters a connection loss error - scenarios in which the database cannot be detached normally and the process may become stuck.

The FORCE option is applicable only for clusters using unlimited storage and is intended primarily for emergency recovery. It is not recommended for routine use.

When the FORCE argument is not included, all outstanding changes are uploaded into remote storage before detaching.

When the FORCE argument is included, SingleStore immediately stops all ongoing uploads and detaches the database. Any data not yet uploaded to remote storage, such as columnstore blobs, rowstore data, or logs, will be lost, resulting in potential data loss. Note that this operation only detaches the database, and does not drop or delete it.

To reattach the database, use the ATTACH DATABASE command. While SingleStore restores the database, any data that was not previously uploaded to remote storage will be missing after reattachment.

KILL

The KILL argument is less disruptive than FORCE, but serves a similar purpose. If detaching a database fails due to a long-running query, you can use the KILL argument to terminate the active query or workload and then proceed with detaching the database.

Unlike FORCE, the KILL argument only stops currently running queries and ensures that all data is uploaded to remote storage before the database is detached. This means that when you later reattach the database, all your data previously uploaded to remote storage will be available. Only the data from the terminated query will be lost, as it was stopped before the detach operation completed.

Remarks

  • If FORCE is not specified, the following apply:

    • A milestone (restore point) is implicitly created via the CREATE MILESTONE command.

    • While the milestone is being created, SingleStore uploads the remote database's local cluster data to remote storage which has not yet been synced.

    • If milestone_name is not specified, a name containing the current timestamp is automatically generated.

  • Once a database is detached, information about that database and its milestones is no longer visible in the MV_* views such as MV_MILESTONES and MV_BOTTOMLESS_DATABASE. The information is available again once the database is reattached.

  • After detaching a database, you can reattach the database using ATTACH DATABASE. The database can be reattached at a milestone or a specified point in time, using either the same database name or the one specified.

  • The BACKUP DATABASE command cannot be run on a detached database. To run the BACKUP DATABASE command, all the partitions of a database must be either in the online or replicating state.

  • This command cannot be run on system databases.

  • Refer to the Permission Matrix for the required permissions.

Examples

DETACH DATABASE db AT MILESTONE "m";
DETACH DATABASE db KILL;

Last modified: November 20, 2025

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined
  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined
  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
    --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
    --bundle undefined \
    --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.