Common DB Schema Change Mistakes
~20 years of experience with various DBMSes, ~15 years with PostgreSQL.
M.S., MIPT and ISP RAS, specialty "Database systems".
Founder of Postgres.ai.
Long-term community activist: #RuPostgres, Postgres.tv.
Committee Chair for Database/Architecture Sections of Highload++, RITFest, etc.
One of the easiest ways to "create a heavy load from nothing" is to write a couple of DDL commands and deploy them to production without thorough analysis and testing.
In this talk, we will discuss several widespread mistakes that many developers and DBAs regularly make during active application development, when there is a need to change DB schema – from adding new database objects or columns to refactoring and optimization of the existing schema.
Special attention will be paid to a few cases that look trivial initially, but in reality, may become the root cause of severe incidents in heavily loaded production systems with strict requirements for uptime and performance.
Finally, based on long-term experience working with fast-growing teams, we will discuss the organizational side of the problem. Namely, we'll try to answer the question: how can we organize the development process so risks of downtime and performance degradation are close to zero but, at the same time, the development teams' throughput steadily grows?
- 2022 April 8 16:20 PDT
- 50 min
- Santa Clara
- Silicon Valley 2022