ALTER TABLE

Schema evolution is catalog-only: channels are independent columnar streams, so nothing is ever rewritten. Adding a column, changing its read-time mechanics or renaming it is a metadata edit that takes effect immediately; only DROP touches data — it purges the channel's stream.

ALTER TABLE telemetry ADD COLUMN door BOOL FILL HOLD STALENESS 60 s;
ALTER TABLE telemetry ALTER COLUMN speed SET FILL NONE SET STALENESS 30 s;
ALTER TABLE telemetry RENAME COLUMN speed TO velocity;
ALTER TABLE telemetry DROP COLUMN old_sensor;

ADD COLUMN

Declares a new channel — same type and attribute syntax as CREATE TABLE. Existing rows simply read null for it; no backfill, no table rewrite, no locking. (Ingesting an unknown field over ILP auto-registers the channel too; ADD COLUMN is how you declare one with FILL HOLD/staleness.)

ALTER COLUMN SET

SET FILL HOLD|NONE and SET STALENESS <duration>|INFINITE change read-time behavior only — fill never touches disk, so the new policy applies to all existing data on the next query.

RENAME COLUMN

Names live in the catalog; the engine addresses channels by id. A rename moves no data and is visible to the next statement.

DROP COLUMN

Removes the declaration and purges the channel's stream: its in-memory delta, its registry entry and its on-disk segments. The channel id is never reused, so re-adding a column with the same name starts empty — old values cannot resurface.

No type changes

ALTER COLUMN ... TYPE does not exist, by design: data on disk already has a shape. The representation-safe conversions, bool/int ↔ f64, are catalog relabels — ask for one by dropping and re-adding only if the history is disposable, or keep the column as f64.

entity and ts are implicit on every table and cannot be added, renamed or dropped.