An open Iceberg lakehouse: plan tables, access and migration
Openhouse combines Iceberg, Trino and dbt on your own object storage. Make table ownership, interoperability and workload fit explicit before migrating an existing lake.
Relevant capabilities
- Iceberg tables on customer object storage
- Trino, dbt modeling and a semantic layer
- Dashboards and data monitors behind LakeGate
How should you compare the options?
- Which engines must read the same tables?
- Who owns schemas, compaction and data quality?
- How will existing warehouse jobs coexist during transition?
What should you bring?
- Table inventory and storage layout
- Transformation jobs and consumer engines
- Access and data-quality requirements
What does a practical first workflow look like?
- Select one dataset with known consumers and acceptance checks.
- Build the table and transformation path alongside the current system.
- Check interoperability and operations before retiring the old path.
What should you check before expanding?
- Validate schema and data reconciliation.
- Test reads from each required engine.
- Review lifecycle, recovery and storage charges.
How should you evaluate the cost?
Compare the cloud bill, platform charges, operating effort and migration work for the same workload. Cloud capacity is not free. Charges and scope need agreement before paid deployment.
What needs checking before switching?
AWS and Google Cloud are available today; other deployment environments are roadmap. Preserve the existing workload and access path until compatibility, recovery and cutover checks pass.