Cloud-Native Data: What is it? - Majors, Dunlap, O’Grady, Richardson, Drewitz
summary
Panel argues cloud-native data needs automation and APIs in all the right places so schema changes and stored procedures stop being blockers, cites Delphix for safe schema testing and Honeycomb for real‑time observability, describes cloning data and building new data lakes for analytics, and notes one org managing ten very large interlinked databases that can’t be treated as disposable. Calls for a new role—database reliability engineering—and practical steps: boundary-driven redesign, clone-and-migrate modernization, and shared tooling so app teams can own small DBs.
AI-written summary · about
chapters (10)
- 0:00Introduction and panel setup
- 1:07Panelist introductions and perspectives
- 5:07Build it you run it for databases
- 10:49Cattle vs pets for databases
- 13:17Stored procedures and automation
- 14:42Schema flexibility in cloud-native
- 17:31Cross-team collaboration for data
- 21:05Culture and failure in data systems
- 27:08Legacy systems and modernization
- 31:06Closing thoughts and Q&A
related talks
35mCloud Native Data Platforms - The why, what and how
28mCloud Native Tech: The Building Blocks of Modern DB Software
22mData Divide: End User’s Cloud Native Journey to Distributed Databases
16mCloud-Native Data Lifecycle Governance for Trusted AI & BI
29mCloud Native Patterns – Shifting Responsibilities
36mIntroducing Data Mesh A Paradigm Shift In Analytical Data Management Architecture
44mRunning Non-Cloud-Native Databases in Cloud-Native Environments
25mCloud Native Data on K8s: The Good, Bad, and the Unknown