Modern Database Design – Do’s and Don’ts

Often the SQL team gets called into design conversations or support escalations from customers where “SQL is slow”.   Upon investigation, it is often the case that the application is written in a curious way that doesn’t use SQL as well as they could.  This leads to high CPU usage, higher costs to run the application, and unhappy end users who can’t get their work done.   As SQL has gotten bigger and more capable, there are more choices that you want to get right to make sure that you get a great experience using it. The goal of the talk will be to show you how to choose among the various storage technologies that exist today (within SQL such as Columnstore, In-memory table, Hyperscale on Azure SQL DB, AlwaysOn Availability Groups Readable Secondaries) and across other offerings in the cloud today (CosmosDB/NoSQL design choices, Azure Data Lake Storage) when building your next application.  To make it entertaining, I’ll share with you real-world escalations (suitably anonymized) of the kinds of questions that eventually come to me in my role as SQL Engine Architect when I get to help customers improve the performance and scale of their applications.  So come hear how far people try to push JSON through SQL without a schema and where the boundary is between NoSQL and relational physical database design (and how people step over that line and keep on going).