Delete Data¶

This page explains how to delete rows from the KDB-X DB Service.

Beta

Delete rows is currently in beta — for evaluation and trial use only. The delete API is under active development: both the endpoint and its behavior may change before general availability.

The DB Service provides an API for deleting rows from a table, including data held in the RDB (in-memory) as well as the IDB and HDB.

Deletion is permanent

Deleted rows cannot be recovered through the DB Service. Back up your data before running a delete operation on production data.

Object storage not supported

Delete operations are rejected if the startTS/endTS time window overlaps with dates held in an object storage tier. Restrict the time window to dates in local HDB tiers only.

Assembly selection¶

Each assembly has its own independent set of tables, so a delete always targets a single assembly. On a deployment configured with more than one assembly, identify the target with the assembly query parameter.

Delete rows¶

Send a POST request to the Service Gateway delete endpoint:

curl -X POST "$SG/api/v0/deletes" \
    -H 'Content-Type: application/json' \
    -d '{"table": "fxquote", "startTS": "2026.01.15D00:00:00", "endTS": "2026.01.16D00:00:00", "filter": []}'

Parameters¶

Parameter	Type	Required	Description
`table`	string	Yes	Table name.
`filter`	list	Yes	List of filter triples `[operator, column, value]` matching the structured query filter syntax. Use `[]` to delete all data in the specified time range.
`startTS`	timestamp	No	Inclusive start boundary.
`endTS`	timestamp	No	Exclusive end boundary.
`session`	string	No	Name for this delete session. Used for status tracking and rollback. If not provided, a session name is generated and returned.

Example: delete a date range¶

# Delete all rows in fxquote for 2026-01-15
curl -X POST "$SG/api/v0/deletes" \
    -H 'Content-Type: application/json' \
    -d '{
        "table": "fxquote",
        "startTS": "2026.01.15",
        "endTS": "2026.01.16",
        "filter": []
    }'

Example: delete rows matching a filter¶

# Delete rows for a specific symbol on 2026-01-15
curl -X POST "$SG/api/v0/deletes" \
    -H 'Content-Type: application/json' \
    -d '{
        "table": "fxquote",
        "startTS": "2026.01.15D00:00:00",
        "endTS": "2026.01.16D00:00:00",
        "filter": [["=", "sym", "EURUSD"]]
    }'

Response¶

Each of the delete requests above returns a response similar to the following:

{
    "name": "54f5cf87-dbc2-4336-d109-173ed56c0b86",
    "updtype": "delete",
    "status": "processing",
    "error": []
}

The name field is the session ID, which can be used to check status as the next example shows.

Check delete status¶

curl "$SG/api/v0/deletes/54f5cf87-dbc2-4336-d109-173ed56c0b86"

The status field progresses through: pending → queued → processing → completed.

If status is errored, the delete was not performed and all rows remain in the database.

Session not found after a Storage Manager restart

If the Storage Manager has restarted since a delete completed — after an out-of-memory condition or a manual restart, for example — a status check for that session can return the error Batch delete session not found. This means the session record is no longer available, not that the delete failed: a delete that had already completed remains applied.

Performance considerations¶

Deleting an entire date partition (all rows for a day) is fast — data is removed directly from disk.
Deleting a subset of rows (e.g. all rows matching sym = "EURUSD") is slower — SM must read and rewrite every column on disk while filtering out matched rows.
If the delete spans multiple dates, delete one date first to measure how long it takes, then proceed with the remaining dates in batches.
Delete is a memory-intensive operation. Other SM operations (batch ingest, EOD) are queued behind it while it runs.

Rollback¶

Delete operations are sequenced in the RT control stream. If you restore from a backup taken before a delete, the delete is replayed on startup — meaning the data is deleted again from the restored backup.

To prevent this during a recovery, set the KXI_IGNORE_DELETE environment variable on SM to the session ID(s) to skip:

KXI_IGNORE_DELETE=54f5cf87-dbc2-4336-d109-173ed56c0b86

Multiple sessions can be specified as a comma-separated list.