I have found the way in the middle is to stick to the traditional things for the most critical work, things where the abilities and problems are well understood, until some of the new thing mature. Then, for less critical things that can run as separate services, try out the new things. That way people in a team can also get exposure to the new technologies and you can experience first hand the pros and cons of these technologies. Some people are more generally optimistic about new things which solves some of the frustrations they have with the old things (or perhaps their lack of experience and understanding of the old things), without realising there will be new problems that comes with the new solutions that haven't even been identified yet, never mind workarounds or solutions to these new, and yet unknown, problems. However, I think the biggest, while also avoidable, risk is usually adopting the new thing for a problem you don't even have. A lot of distributed databases exist because you are going to have a lot of concurrent users access similar data, related to themselves mostly, accessed at the same time, or have a lot of user data that you want to do big, ad-hoc searches and analysis across all the data. If you don't have the scale of 'a lot' or 'concurrent' or 'across all the data' that these things are designed to address, you might not even need this solution and especially not all the tradeoffs you have to make along with it. I agree it's an exciting time, and a time of discovery for everyone, but there will be many things learned the hard way and it's tricky to position yourself here especially when there's pressure around you.