@venkatveeramanidaasan said:

"Graybeard: Yup. And considering that they take all the operations headache from you it might be a good solution. Google has BigQuery, Amazon has Redshift, there’s compose and many others. An extra benefit for BigQuery and Redshift is that they scale. Both claim they can process billions of records in seconds

Referring to the above text from the book. I have an observation here.
Before that point, you are talking about MySQL, Postgres and NoSQL. Then, it talks about not OLTP databases like BigQuery and Redshift etc.
Does is need some context around. Depends on the storage/app need you are suggesting these databases.
otherwise, it gives an impression that Redshift can be use like a OLTP database.
Does it* need...
Also, I see you have said below: start with shelve or simple and at later stage choose the correct DB. But, I am not sure whether a upfront context with usage of keyword like for Data intensive analytical load go for Redshift etc.

"Graybeard: Yeah, too many options is not a good thing. Remember this when we’ll talk about monitoring. But for now - just start with shelve or something simple as it. When things get more interesting - go over the queries you do, the business requirements and then select the right solution. Who knows? You might find yourself using a graph database at the end."

"Graybeard: Yup. Note that there are deploys and there are deploys. Most of them will be a non issue, but some of them will give you a headache."

there are deploys and there are deploys

intentional?

Add a chapter on UI/UX (suggested by Markus Monderkamp)

Frameworks:

• Qt
• Tkinter
• FLTK
• wx
• curses
• web