Let me just start by quoting Amazon's DynamoDB FAQ
Q: When should I use Amazon DynamoDB vs a relational database engine on Amazon RDS or Amazon EC2?
Today’s web-based applications generate and consume massive amounts of
data. For example, an online game might start out with only a few
thousand users and a light database workload consisting of 10 writes
per second and 50 reads per second. However, if the game becomes
successful, it may rapidly grow to millions of users and generate tens
(or even hundreds) of thousands of writes and reads per second. It may
also create terabytes or more of data per day. Developing your
applications against Amazon DynamoDB enables you to start small and
simply dial-up your request capacity for a table as your requirements
scale, without incurring downtime. You pay highly cost-efficient rates
for the request capacity you provision, and let Amazon DynamoDB do the
work over partitioning your data and traffic over sufficient server
capacity to meet your needs. Amazon DynamoDB does the database
management and administration, and you simply store and request your
data. Automatic replication and failover provides built-in fault
tolerance, high availability, and data durability. Amazon DynamoDB
gives you the peace of mind that your database is fully managed and
can grow with your application requirements.
While Amazon DynamoDB tackles the core problems of database
scalability, management, performance, and reliability, it does not
have all the functionality of a relational database. It does not
support complex relational queries (e.g. joins) or complex
transactions. If your workload requires this functionality, or you are
looking for compatibility with an existing relational engine, you may
wish to run a relational engine on Amazon RDS or Amazon EC2. While
relational database engines provide robust features and functionality,
scaling a workload beyond a single relational database instance is
highly complex and requires significant time and expertise. As such,
if you anticipate scaling requirements for your new application and do
not need relational features, Amazon DynamoDB may be the best choice
Are you even expecting a few thousand users? Do you have any concern with a sudden spike to millions of users? You've already stated that you need "complex relational queries" to use the terminology from the quote. Choosing a key-value/document store is not just saying "I don't need those now" but also "and I will never need those".
The quote also paints an overly rosy picture of NoSQL key-value/document stores. The weakened consistency guarantees lead to a significant amount of extra complexity in the application code to get correctness. My strong impression is that many developers using NoSQL key-value/document stores, just pretend that they have these consistency guarantees (or rather, don't realize that they don't) and write subtly broken code. (Cue the multiple Bitcoin exchanges that got "hacked" because they wrote code against NoSQL databases assuming they provided more consistency than they do.) There are some things that you just can't do with a NoSQL key-value/document store without basically manually reimplementing some of the trickiest parts of a relational database.
My general advice is that a relational database should be the default choice. Realistically, a system using a NoSQL data store will almost certainly have (or benefit from) a relational database as well, so the real question is, "is there any reason to also have a NoSQL data store?" The benefits of relational databases is that they are some of the most battle-tested software systems on the planet, are full-featured, and are very unlikely to leave you boxed in a corner where implementing certain functionality is just "impossible". Read-heavy loads are not problematic for relational databases, but even if they were the solution to that would be caching. You may even use a NoSQL key-value/document store for that cache! That would be a very good use of a NoSQL solution.
Relational database are likely to be completely adequate for many users needs performance-wise. They simplify and speed up development by presenting a much simpler consistency model and providing more features out-of-the-box. There's likely to be some data where consistency is important and latency isn't important; these are well-served by a relational database. There is also likely to be data where latency is more important and up-to-date consistency less so; caching handles this well and NoSQL solutions often shine here (assuming normal HTTP caching doesn't suffice). If your system does need to scale, you are most likely looking at a hybrid system, not a transition to a different data storage technology altogether.
(There are some application domains where it makes sense to design the system from the get-go for weak consistency to achieve low-latency, e.g. online, multiplayer, first-person shooter games. But this isn't most systems, or at the very least it's a choice between paying for a complicated low-latency design now or paying for it later when you have more information about the requirements and load [and likely more money and expertise].)