← All speakers

Bio, Work & Ideas

Ben Dicken

Conference affiliation: PlanetScale

On this page

Ben Dicken is a developer educator and software engineer whose work combines database instruction, performance benchmarking, and customer support. His work at PlanetScale and his independent projects make the machinery beneath software visible: interactive simulations and practical experiments help developers understand why systems behave as they do and how to improve them.

From introductory programming to database scaling

Dicken’s career moved from research software engineering at Dataware into teaching computer science at the University of Arizona, then into developer education at PlanetScale. He earned his bachelor’s and master’s degrees at Arizona and returned as a lecturer. In the 2017–2018 academic year, he received the department’s Outstanding Faculty Teaching Award for developing CSC 101, an introductory course serving students with no previous computer science experience, including non-majors.

His Database Scaling course, released in February 2024, carries that teaching approach into the operational decisions behind growing applications. It follows a fictional game studio as demand for its product grows. Partitioning, replication, sharding, caching, and connection management become responses to an evolving application, with animations and demonstrations using MySQL and PlanetScale explaining how the techniques work.

His independent projects extend this approach beyond database courses. They include visual tools for B-trees and B+ trees, the beginner-oriented Python learning site Pyflo, and experiments with browser graphics. His open-source Languages project explores programming languages, compilers, interpreters, and toolchains through microbenchmarks. It is a collaborative learning project, with implementations and measurement improvements contributed by its community.

Making performance understandable

Dicken connects low-level computer behavior to choices developers make in production. His explanations often begin with something readers can manipulate or measure, then develop the implications for larger systems:

  • Processes, threads, and database connections: His interactive explainer uses a simplified instruction set and controllable CPU simulations to show programs executing, yielding, and sharing resources. He connects those mechanisms to PostgreSQL’s process-per-connection architecture, MySQL’s use of threads, and connection pooling. Readers can see the work a computer performs before examining the database tradeoffs that depend on it.
  • Memory access patterns: In a hands-on performance investigation, Dicken compares two C programs that perform the same number of memory writes but traverse differently sized allocations. On his test machine, repeatedly revisiting the smaller allocation takes longer. He uses that surprising result to explain virtual memory, paging, and access patterns, showing why an operation count alone cannot predict performance.
  • Database benchmarking: In his account of PlanetScale’s PostgreSQL benchmarking, Dicken explains how the team used its internal Telescope tool to run and assess benchmarks during product development. He distinguishes basic query latency, transaction workloads, and read performance while acknowledging that no benchmark predicts every application’s behavior. His later benchmarking guidance examines a consequential measurement problem: a client that waits for each response stops generating requests when a database stalls, concealing the queue that would form under continuing production demand. He also argues for reporting latency distributions, variation across runs, and enough configuration detail to reproduce the measurements.

Keeping applications useful under load

Dicken approaches overload by asking which user activities must survive. His PostgreSQL traffic-prioritization example distinguishes authentication and reading posts from lower-priority impression counts and analytics. Query tags identify categories of work, and resource budgets constrain their consumption. Shedding less essential work can preserve a usable application during a surge.

His 2026 talk on scaling databases for the AI era extends that reasoning to agents that generate traffic and change infrastructure. He argues that good developer experience also provides useful primitives for agents: a Vitess VSchema JSON file gives an agent a concrete way to express a sharding plan; Traffic Control budgets limit resource consumption; and database branching, deploy requests, and reverts provide ways to manage schema changes. These mechanisms connect his teaching and performance work to a practical question for AI applications: how to move quickly while keeping database failures and overload manageable.

Read the topics behind these talks

1 conference talk

Key ideas

Scroll to read ↓

Ben Dicken explains how PlanetScale combines isolation, redundancy, sharding and backpressure—and how configuration files, traffic budgets and schema branches give agents useful ways to operate that infrastructure.

  • Isolation contains a component’s failure; redundancy provides a replacement when a server fails. Growing fleets need both because individual failures become routine.
    3:24 ↗
  • Sharding distributes capacity, backpressure limits overload, and decoupling lets workloads scale independently. Each solves a different problem.
    6:53 ↗
  • A VSchema gives an agent a text configuration to help design while Vitess and VTGate operate the query-routing machinery.
    12:23 ↗
  • Traffic Control assigns resource budgets to tagged traffic, with warnings or query termination providing explicit responses to overload.
    14:53 ↗
  • Schema branches, deploy requests and supported reverts give agents useful change-management operations, with human review available as part of the workflow.
    16:22 ↗