GitHub user vishnu-chalil closed a discussion: Design Rationale for Single-Type Catalogs vs. Unified Alternatives
Dear Gravitino Community, I’ve been evaluating Apache Gravitino’s catalog architecture and noticed that each catalog instance is designed to support only one type of data (e.g., relational, file-based, or messaging). While this separation seems intentional, I’m curious about the trade-offs compared to unified catalog designs like Open Source Unity Catalog (OSUC), which allows multiple data types (tables, files, ML models, etc.) within a single catalog. Could you elaborate on: Design Philosophy: What motivated Gravitino’s choice to enforce single-type catalogs, and were unified alternatives (like OSUC) considered? Advantages/Disadvantages: How does this approach improve scalability, performance, or metadata isolation compared to unified models? Are there limitations (e.g., cross-type queries) that users should anticipate? Future Flexibility: Are there plans to support hybrid use cases (e.g., file-to-table lineage) across catalogs, or is the separation considered a long-term design constraint? I’m particularly interested in how Gravitino’s approach aligns with polyglot data ecosystems (e.g., lakes with mixed formats) versus solutions like OSUC that unify metadata under one interface. Any insights or relevant design docs would be greatly appreciated! GitHub link: https://github.com/apache/gravitino/discussions/7135 ---- This is an automatically sent email for dev@gravitino.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@gravitino.apache.org
