interviewpath
  • 0day streak
  • 10total XP
  • Level 1

Focus mode

Database paper route: CMU courses to Spanner

Read alongside

CMU 15-445/645 Intro to Database Systems: Fall 2025 schedule (lecture notes, slides and videos)

Foundations to refresh before the papers; the notes are the fastest route.

Objectives

  • Build a working vocabulary from 15-445 lectures so that papers can be read for their contributions rather than their definitions.
  • Record problem, assumptions, mechanism, evidence and limitations for each core paper in structured notes.
  • Classify the claims in each paper as algorithmic ideas, workload-dependent results or guaranteed semantics.
  • Explain Spanner’s external-consistency guarantee and its dependency on TrueTime, and contrast it with Calvin’s deterministic approach.
  • Present one route paper in 2, 10 and 45 minutes, including a critique of its evaluation.
  • Formulate one research question that follows from a limitation identified on the route.

Why it matters

Database research builds on a shared canon, and interviewers for research internships and thesis positions expect you to discuss a few core papers precisely: what they claim, how they support it and what they leave open. Reading in a deliberate order is faster than reading at random, because each paper supplies the vocabulary for the next.

Core ideas

Three kinds of claims. Keep three columns in your notes for every paper:

  1. Algorithmic or design ideas: a data structure, a protocol, an execution model.
  2. Workload-dependent results: throughput, latency or speedups that hold for the tested hardware, data and configuration.
  3. Guaranteed semantics: serializability, external consistency or atomicity that follow from an argument under stated assumptions. Spanner contains all three: TrueTime and commit wait (design), external consistency given a correct uncertainty bound (guarantee), and microbenchmark and production latencies (measurements). Mixing the columns is an easy mistake when discussing it, for example treating a measured latency as a property of the design.

The core path. These three papers have guides in this app and are scheduled with this topic, in this order:

  1. A Critique of ANSI SQL Isolation Levels: the semantics vocabulary, including snapshot isolation and write skew. Short and theory-only.
  2. How Good Are Query Optimizers, Really?: a model of careful experimental method on a hard problem.
  3. Spanner: the capstone, where transaction semantics, replication, clocks and evaluation meet. Before the core path, make sure the 15-445 material on concurrency control, recovery and query optimization is fresh, and skim Architecture of a Database System to see how the components fit together.

Extensions, by interest. Each adds a few hours:

  • Isolation in practice: Serializable Snapshot Isolation in PostgreSQL.
  • Storage: the LSM-tree paper, then the RUM conjecture, connected to the RocksDB documentation.
  • Execution: MonetDB/X100, Neumann's compilation paper, then Kersten et al.'s controlled comparison.
  • Learned components: the learned-index paper with its benchmark, or MSCN with "Are We Ready For Learned Cardinality Estimation?".
  • Concurrency control at scale: Yu et al. and Wu et al.
  • Distributed transactions: Calvin and Harding et al. as contrasts to Spanner. The CMU 15-721 schedules list readings per lecture; use them to go deeper in the area you might choose for a project rather than reading everything.

How to read. Use three passes: overview, mechanism, evaluation. Fill the structured notes (problem, assumptions, mechanism, contribution, evidence, baselines, ablations, limitations, implementation, follow-up) before moving on, and write one question you would ask the authors.

Common misconceptions

  • "Reading more papers is the goal." Depth on a handful you can defend beats skimming many.
  • "A paper's numbers are its contribution." Numbers are evidence for a claim under a setup; the transferable contribution is usually the idea or the method.
  • "Classic papers are outdated." Their hardware assumptions may be dated, but later work builds on their vocabulary and arguments; note which assumptions changed.
  • "A paper's guarantee applies to every system using the idea." It holds under the paper's assumptions and for correct implementations; check both.

How to approach it

Schedule the core path over two to three weeks alongside the research-methods topics, and add one extension that matches your interests. After each paper, explain its main idea aloud in two minutes. Before an interview, prepare a 10-minute presentation on Spanner or on Leis et al. that includes a critique of the evaluation, and be explicit about what you reproduced yourself and what you only read.

Self-check before you finish

  1. Which of Spanner’s claims are guarantees, and what assumption do they depend on?
  2. Which experimental method from Leis et al. would you reuse for a different optimizer component?
  3. How does write skew connect the Critique paper to PostgreSQL’s SSI?
  4. What would you ask the Spanner authors about their evaluation?
  5. Which extension did you choose, and what question does it open for a project?