Matt Freels

Always fun talking to developers about what databases they're using, what is/isn't working, and how we can solve real pain and help them move faster. Be sure to drop by the @fauna booth in the expo if you're at @AWSreInvent !

There's an interesting disconnect between the religious fervor for SQL that has emerged over the last few years and the views of engineering leaders in my network that have experienced the pain of configuring/managing/scaling current SQL offerings, debugging complex/opaque performance issues stemming from ORM translation/query planner choices, etc. in the real world. The SQL (re-)hype seems driven by the realization that relational features such as transactions, strong consistency, schema/enforcement, and first-class relationships are critical and are missing (or half-baked) in many NoSQL databases, which is very valid. But those features aren't intrinsically bound to SQL as a DQL/DML and they are front and center in modern NoSQL databases like @Fauna. SQL was developed in the 1970s for humans writing analytical queries; it wasn't designed for operational databases that are primarily consumed by applications and the object–relational impedance mismatch is a real problem. The biggest benefit today is that it is a widely adopted standard, with many practitioners and a lot of tooling built around it. But languages and standards change over time, and the state of the art in operational databases has advanced to the point where that benefit typically isn't worth the cost.