Can Logs Be Modified? SLS LogStore Adds Native Update and Delete Support

We are the Alibaba Cloud Log Service (SLS) team. For over a decade, LogStore stored logs in an immutable, append‑only fashion, which gave the system high throughput, low cost, and reliable audit semantics. Recently we added native update and delete capabilities and discuss the motivations, design choices, and usage patterns.

Stage 1 – Logs for Human Reading

Initially logs were only read by operators using commands like tail -f or grep. The design principle was simple: append‑only, never modify , ensuring lock‑free writes, time‑ordered storage, and stable consumption offsets.

Stage 2 – Logs for Analysis

Logs became structured, indexed, and queryable via SQL, SPL, and machine‑learning operators. They now serve risk‑control, monitoring, BI, and other downstream systems, but the underlying write path remained append‑only.

Stage 3 – Logs Carry Business Semantics

Business use cases increasingly require correction, back‑fill, overwrite, or cleanup of existing log records, such as billing adjustments, model‑driven feature recomputation, risk‑score updates, and delayed user feedback.

Design Trade‑offs

Explicit Enablement : Update/delete is only available when the LogStore property enableModify=true is set (once enabled it cannot be disabled).

Append‑Only Write Path Preserved : New data continues to be appended without deduplication; modifications are performed via separate update / delete requests referencing __rowid__ or query conditions.

Synchronous Visibility : After a successful API call, subsequent queries see the updated or deleted records, guaranteeing that consecutive updates operate on the latest state.

Unchanged Query Experience : Existing Search, SQL, and SPL interfaces remain the same; modified data is reflected automatically without changing downstream pipelines.

Row‑Level Addressing

When enableModify=true each log entry receives a stable internal identifier __rowid__. This identifier is not a business primary key; it is used solely for locating a specific record for precise updates or deletions.

Update/Delete APIs

Two operation modes are supported:

Point Update/Delete by specifying a single __rowid__.

Batch Update/Delete by providing a time range and a query expression that matches the target records.

Example of a point update:

client.update_logs(
    project="ops",
    logstore="work-orders",
    rowid="1|1048576|63",  # __rowid__ from a query result
    log_item={
        "status": "contacted",
        "handler": "alice",
        "handled_at": now,
    },
)

Example of a batch update for risk‑score refresh:

client.update_logs(
    project="risk",
    logstore="transactions",
    from_time=seven_days_ago,
    to_time=now,
    query='merchant_id:"M-2049" and risk_level:"medium"',
    log_item={
        "risk_level": "high",
        "risk_model_version": "v3.2",
        "re_evaluated_at": now,
    },
)

Typical Scenarios

Billing Corrections : After month‑end, adjust amounts, reasons, and timestamps for specific accounts using billing_period, instance_id, etc.

Risk‑Control Label Refresh : Re‑evaluate historical transactions with a new model and update risk_level from "medium" to "high".

LLM/Agent Feedback : Back‑fill delayed user feedback, quality scores, or audit results into the original request record identified by request_id and trace_id.

Operational Edits : Customer‑service agents modify order status or administrators correct mis‑labelled data via a UI that queries for a row and then updates it by __rowid__.

Limitations and Best Practices

Batch operations are limited to a maximum of 10,000 matched rows; large jobs should be split by business dimensions (e.g., by billing period, batch ID, or time window).

Because index construction is asynchronous, queries used in batch updates should be executed after the data becomes searchable; this mode is unsuitable for "write‑then‑immediately‑modify" scenarios.

Conclusion

Traditional log use cases still favor immutability, but modern workloads treat logs as a flexible data source that occasionally needs correction. Enabling enableModify=true provides a direct, low‑latency path for such updates without sacrificing LogStore’s core strengths of high throughput, low cost, and stable consumption semantics.