Choosing a Lambda Architecture to develop a Data Lake for your enterprise does incur some inherent disadvantages if some of its aspects are not fully thought through. Some of these are as follows:

• Due to its different layers, it is generally considered to be complex. Keeping sync between these two layers incurs cost and effort, and this has to be thought through and handled.
• Because of these two distinct and fully distributed layers (batch and speed), maintenance and support activities are quite hard.
• There are a good number of technologies that have to be mastered to construct a Lambda-Architecture-driven Data Lake. Getting people who have expertise in these technologies can be troublesome for your recruitment division.
• Implementing a Lambda Architecture with open sources technologies and then deploying in the cloud can be troublesome. To avoid this, you could very well use cloud technologies to implement Lambda Architecture, but by doing so, the enterprise automatically gets itself tied to a particular cloud provider and that inherently is considered a disadvantage.
• Even though the architecture pattern has been around for quite some time now, the tools are still immature and evolving. Cloud evolution has surely accelerated and innovated in this space so it won't be long before we get mature solutions and tools in this space.
• CI/ CD is now a requirement and not at all a luxury. As tools in this space are still not that mature, tools in regards to CI/ CD also fall into the same category, making it hard to do many automations.
• The setup could require a good amount of hardware components. Technically, low end hardware components can be used but for enterprise grade, usually high end is considered with a well-defined support model with vendors.
• The architecture pattern has always been criticized for implementing the same job twice (batch and speed layer).