I left this book feeling much more comfortable in SQL, but also much less confident in SQL. This review is as much about SQL as the book itself, but as a member of the book’s target audience, these are concerns the book would do well to address.
It raised as many questions as it answered, so as an application developer, I don’t feel safe taking too hard a dependency on Postgres, in case I run into an unforeseen scalability issue and have to rewrite in favor of a custom data system.
I know I’m being pretentious, assuming I’ll have scaling problems, which are rare except for the biggest companies, and even then with particular usage patterns. But at some level, the book has to argue for postgres on perf grounds. Although it tries to argue for expressivity of SQL, it’s pretty clearly lacking compared to eg. the author’s Common LISP, despite the author compellingly arguing it’s more succinct than eg. Java or OO-style Python.
The book did not cover how to read an EXPLAIN plan, which I think would have helped. I realize the book chose to keep that out of scope, which is why I’ll try follow it up with one diving in to db perf. The problem is that when you ask me to write more complex SQL queries, I lose the ability to plan about their perf, in 1) will the latency become unacceptable with more rows and 2) will it monopolize resources with too many queries and degrade throughput, and 3) will even “easy” queries have high latency, but I won’t guess until I’ve wrote myself into a hole?
If I’m only writing simple queries, and aggregating in eg. a Python app layer, I can at least reason about their performance, even if it’s poor.