Skip to content
shadcn.io

shadcn.io is not affiliated with official shadcn/ui

Database Migrations Timeline Block for React

Seven schema migrations on a rail with the SQL of each, and a Schema as of slider that shows the tables and columns after any migration, worked out by applying the typed operations in order, with the touched tables marked changed.

Framework
UI library

Preview

Preview width

Installation

Part of Pro
Pro unlocks the code and one-line install of every Pro button and text effect, plus the MCP for your AI editor.
Have Pro already? Sign in to open it.Opens here as soon as you're Pro.

Overview

Scrub through the history of a database schema, and see the tables as they stood after each change, with this database migrations timeline for React with Base UI. It is written for Schemaslide, a fictional schema versioning tool, and one billing database. A hairline frame with a plus mark on each corner holds a stepped Slider "Schema as of" over a vertical rail of seven migrations, 0036 to 0042. Each has its id in mono, the date, the run time, the operation words (CREATE, ALTER, DROP) and the SQL of each operation. Nodes up to the slider are solid, the one at the slider is ringed and the ones after it are dashed, with the rail dashed from there on. In the end cell the tables and columns at that point are worked out by applying the typed operations to the starting schema in order, and the tables the selected migration touched say "changed". The slider sits in a left to right box in every language, the cell keeps the height of the tallest schema so sliding moves nothing, and on a phone it stacks under the rail. A polite status line says the table and column counts when you let go of the thumb. It is built from Slider, Badge, Direction Provider, Guides and a CSS entrance. For migration tools, schema docs and database dashboards. The migrations are example data.

FAQ

How do I change the migrations?

Edit BASE (the schema before the first migration) and MIGRATIONS at the top of the file. A migration has an id, a date, the run time and a list of operations, each a short typed line: create table col:type …, add table col:type, drop table col, rename table old>new or drop-table table. The SQL shown, the operation words and every schema are derived from those lines by applyOp, so nothing is typed twice.

How is the schema worked out?

SCHEMAS applies the operations of each migration to the schema before it, once, at the top of the file. The slider position just picks one of them. A table dropped by a later migration is gone from every schema after it, and a renamed column keeps its type.

Why does the slider stay left to right in Arabic or Hebrew?

The rail is a sequence in time and the slider moves along it, like a chart axis, so it keeps one direction in every language. The rail's text and the rest of the block follow the page direction; SQL and ids always stay left to right.

What stays in the page, and how do I use real migrations?

Only the slider's position, which is local state; nothing is fetched or run. To use real migrations, read your tool's migration table for the ids, dates and run times, and either parse its SQL into these typed operations or take the schema after each step from a snapshot.

Is it accessible?

The slider has a name, "Schema as of", and reads out the migration id as its value, with the keyboard arrows and Home and End. The result is announced politely from the status line when you let go. The rail is an ordered list with a heading per migration, and the state of each node is also its position relative to the slider, not colour alone.

How does it look on a phone?

The slider fills the width, the rail comes next and the schema stacks under it with the same height as at any other position.