Training: June 20–21, 2016
Tutorials: June 21, 2016
Keynotes & Sessions: June 22–23, 2016
Santa Clara, CA

Maslow's hierarchy of needs for databases

Charity Majors (Honeycomb)
2:10pm–2:50pm Thursday, 06/23/2016
Location: Mission City Ballroom M1 - 2 Level: Intermediate
Average rating: *****
(5.00, 6 ratings)

It’s easy to say, you should always automate everything, monitor everything, and instrument every inch of your data infra. But overengineering in advance of your needs can be just as costly as the reverse, particularly for startups. Engineering cycles are scarce. How do you decide where to spend them?

Enter Maslow’s hierarchy of needs—for databases.

For humans, Maslow’s hierarchy of needs is a pyramid of desires that must be satisfied for us to flourish: survival, safety, love and belonging, esteem, and self-actualization. Each level depends on the preceding ones—we need survival before safety, safety before love and belonging, etc.

Really, databases aren’t so different from you and me. They need:

  • Survival: Do you even have a data store? How should you decide what storage systems to run? Is it up? Is it alive? Do you have backups? Are they valid?
  • Safety: Are there multiple live copies? Are they geographically distributed? What is your failover story? Are your humans redundant too?
  • Love and belonging: Are your databases first-class citizens of your engineering processes, and do they share config management and tooling with the rest of the org? Are schema changes defined in code and revertable? Have you eliminated special snowflakes?
  • Esteem: Can your observability stack surface problems before they impact production? Can you correlate events across the stack? Can you automatically remediate common failures without human intervention? How do your observability requirements evolve as your org matures?
  • Self-actualization: Is your data store its best possible self, and what does that even mean for your org? (The self-actualized, maturely instrumented storage layer for a website with 1 billion users will look very different from the self-actualized storage layer for a young and highly volatile startup environment.) How can you assess your appetite for risk, your stage of development, and the layers of process you should invest in organizationally at each stage?

Charity Majors outlines DevOps/DBA best practices from the earliest seed stages (survival, selecting the right storage layer, etc.) to what you should expect from a mature, self-actualized database tier and offers a roadmap for how practices should evolve alongside the org as it grows up. Along the way, Charity explores how to ensure that your database is a first-class citizen of your engineering and operational processes and dives into some war stories and relevant tooling for MongoDB and MySQL shops in particular.

Photo of Charity Majors

Charity Majors


Charity Majors is the cofounder and CTO of Honeycomb, a new startup focused on mining machine data. Previously, Charity ran infrastructure at Parse and was an engineering manager at Facebook. She also worked with the RocksDB team to build and deploy the world’s first Mongo + Rocks in production. Charity likes single malt scotch.