← All posts

Designing schema evolution nobody notices

Additive changes ship instantly. Breaking ones backfill in the background while v1 keeps serving.

Designing schema evolution nobody notices

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.

Sigrún leads the query engine team in Reykjavík. Before Basalt she worked on storage at a Nordic payments company, where she learned to distrust any latency number without a percentile next to it.

Get started

Set your data in stone.

Free up to 10M events a month. No card, no sales call. Your first pipeline is live in about four minutes.

Project reserved · check your inbox
That didn't go through · check the address and try again
2,400+ teams in productionSOC 2 Type II38 regions