Designing schema evolution nobody notices
Additive changes ship instantly. Breaking ones backfill in the background while v1 keeps serving.
The best schema change is the one your API consumers never hear about. We designed Basalt so most changes are exactly that.
Additive changes are instant
Adding a column or a new event field is a metadata change. New writes carry the field, old rows return null, and every view keeps serving without a deploy.
Breaking changes run side by side
Basalt builds v2 of the view in the background from the log.
v1 keeps serving until v2 has caught up to the present.
You switch traffic with one click, and can switch back.
In the console the whole flow is one screen with a progress bar and a diff of the two schemas. Teams ran 4,100 breaking migrations last quarter with no downtime.
More from the engine room.
How we cut p99 from 11 ms to 4.2 ms
Three changes to the read path in v4.0: declared sort keys, a per-core allocator and a planner that stopped re-sorting partitions at query time.
Exactly-once without two-phase commit
Idempotent sinks, epoch fencing and a 64-bit sequence per partition. No coordinator, no stalls.
Time travel is just a really good index
Why AS OF queries on 30 days of history cost less than one extra replica.
