Vendor lock-in is dependence on a particular software tool or vendor that makes changing platforms difficult or costly. Proprietary storage formats, indexing strategies, and query semantics can make data and applications hard to move, tying organizations to one analytics platform. section 1.3
A modular lakehouse reduces this dependence by separating storage, ingestion, catalog, federation, and consumption. Open standards such as Apache Iceberg let organizations choose tools for each layer, scale components independently, and replace individual services as needs evolve. section 2.7
Assess lock-in across the lakehouse architecture:
- Storage systems using standard APIs and protocols ease connections to ingestion tools, processing engines, and query services; proprietary interfaces require custom integrations. section 5.1.4
- Managed services can reduce deployment and maintenance effort but may introduce vendor lock-in and usage-based costs that grow over time. section 7.2.5
- Self-managed open-source catalogs may avoid licensing fees but require engineering effort for deployment, security, upgrades, scaling, and high availability. section 7.2.5
Choosing a catalog
A managed catalog may simplify monitoring, deployment, and maintenance while increasing dependence on its vendor. A self-managed open-source catalog can improve control and avoid licensing fees, but shifts operational work to the engineering team. section 7.2.5
Figure 2.6 Components of a complete data lakehouse implementation
Use the lakehouse component diagram to trace where modular boundaries and open standards can reduce dependence on a single vendor. section 2.7
