# First Migration Record

> The very first migration. Where it all began.

Canonical URL: <https://datadriven.io/problems/first_migration_record>

Domain: SQL · Difficulty: easy · Seniority: L3 · Asked in: Google

## Problem

Pull the very first migration ever applied to the schema, identified by the smallest migration ID. Show all available fields: migration ID, version, status, applied date, rollback info, duration, author, and database name.

## Tables

### migrations

- migr_id INTEGER
- version TEXT
- status TEXT
- applied TEXT
- rollback TEXT
- dur_ms INTEGER
- author TEXT
- db_name TEXT

Sample rows (10 of 200):

| migr_id | version | status | applied | rollback | dur_ms | author | db_name |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 123 | 002_add_users | pending | 2026-02-02 01:00:00 | DROP TABLE IF EXISTS tbl_1 | 41 | bob | staging_main |
| 146 | 003_add_orders | failed | 2026-03-03 02:00:00 | DROP TABLE IF EXISTS tbl_2 | 72 | charlie | analytics |
| 169 | 004_indexes | rolled_back | 2026-04-04 03:00:00 | DROP TABLE IF EXISTS tbl_3 | 103 | dana | reporting |
| 192 | 005_add_products | Applied | 2026-05-05 04:00:00 | DROP TABLE IF EXISTS tbl_4 | 134 | migration-bot | archive |
| 215 | 006_add_sessions | PENDING | NULL | DROP TABLE IF EXISTS tbl_5 | NULL | Alice | prod_main |
| 238 | 007_add_events | applied | 2026-07-07 06:00:00 | DROP TABLE IF EXISTS tbl_6 | 196 | alice | staging_main |
| 261 | 008_add_search | pending | 2026-08-08 07:00:00 | NULL | 227 | bob | analytics |
| 284 | v009_payments | failed | 2026-09-09 08:00:00 | DROP TABLE IF EXISTS tbl_8 | 258 | charlie | reporting |
| 307 | V010_analytics | rolled_back | 2026-01-10 09:00:00 | DROP TABLE IF EXISTS tbl_9 | 289 | dana | archive |
| 330 | 001_init | Applied | NULL | DROP TABLE IF EXISTS tbl_10 | NULL | migration-bot | prod_main |

## Expected output

First 1 of 1 rows:

| migr_id | version | status | applied | rollback | dur_ms | author | db_name |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 123 | 002_add_users | pending | 2026-02-02 01:00:00 | DROP TABLE IF EXISTS tbl_1 | 41 | bob | staging_main |

## Worked solution and explanation

### Why this problem exists in real interviews

The `migrations` schema makes this a clean test of row numbering within partitions combined with nested subqueries. Columns like `version`, `status`, `applied` introduce enough ambiguity that only candidates who clarify assumptions produce correct results.

---

### Break down the requirements

#### Step 1: Partition by `db_name`

Find the smallest migration ID across the whole table with a scalar subquery: (SELECT MIN(`migr_id`) FROM migrations).

#### Step 2: Filter to rank 1

Select the full row (all available fields) whose `migr_id` equals that minimum.

---

### The solution

**Row-number for first migration record**

```sql
SELECT * FROM migrations WHERE migr_id = (SELECT MIN(migr_id) FROM migrations)
```

> **Cost Analysis**
>
> Window function sorts within each `db_name` partition. An index on `(db_name, applied)` avoids a full sort.

> **Interviewers Watch For**
>
> The interviewer checks whether you use `ROW_NUMBER` (one row) vs. RANK/`DENSE_RANK` (ties) based on the prompt requirements.

> **Common Pitfall**
>
> Using GROUP BY with MIN(applied) gives the value but not the other columns. `ROW_NUMBER` gives the full row.

---

## Common follow-up questions

- The `rollback` column in `migrations` has roughly 70% NULLs. How does your query handle those rows, and would the result change if NULLs were replaced with zeros? _(Tests whether the candidate understands how NULLs propagate through aggregation functions and whether their WHERE/JOIN conditions implicitly filter them out.)_
- Your window function uses a default frame. What is the implicit frame, and would switching to ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW change anything? _(Tests knowledge of default window frames (RANGE vs ROWS) and when the distinction matters.)_
- The `version` column in `migrations` has a zipf distribution, meaning a few values dominate. How does that skew affect your query plan and parallelism? _(Tests understanding of data skew: the optimizer may choose a bad plan when histogram statistics are stale.)_
- How would you modify this query to run incrementally as new rows arrive in `migrations` each hour? _(Tests whether the candidate can think about incremental computation vs full recomputation.)_

## Related

- [All practice problems](https://datadriven.io/problems)
- [Mock interview mode](https://datadriven.io/interview/first_migration_record)
- [SQL Interview Questions](https://datadriven.io/sql-interview-questions)
- [Data Engineering Interview Prep Guide](https://datadriven.io/data-engineer-interview-prep)
- [Daily Challenge](https://datadriven.io/daily)

---

Source: DataDriven (https://datadriven.io). DataDriven is the data engineering interview community. Live code execution in SQL, Python, and Spark sandboxes. Every feature is open to every member.