SQL and Graph Analytics on Apache Iceberg with Starburst and PuppyGraph

Data lakehouse architectures have become a common foundation for modern analytics platforms, providing a cost-effective way to store and analyze large volumes of enterprise data. Apache Iceberg introduces powerful data management capabilities for lakehouses, including reliable metadata handling, schema evolution, and efficient query performance at scale. To fully utilize these capabilities, a high-performance query engine is required. Starburst’s Icehouse architecture, powered by Trino, provides an efficient way to run distributed SQL analytics directly on Apache Iceberg, as well as providing a data foundation and context layer for AI workloads

While SQL remains the primary interface for large-scale analytics, some questions are easier to answer when data is viewed as a graph. Relationship-oriented analysis such as tracing transaction flows, identifying dependencies, or exploring multi-hop interactions, often requires graph queries. By combining Trino for SQL analytics with PuppyGraph for graph analytics, teams can analyze the same Iceberg data using both query models. This approach allows SQL and graph queries to operate on the same data without copying it into a separate graph database.

SQL Analytics on Apache Iceberg with Trino

Trino is widely used to run distributed SQL analytics on Apache Iceberg tables in modern lakehouse architectures. Using its Iceberg connector, Trino can query Iceberg tables stored in object storage while relying on Iceberg’s metadata layer to track table snapshots, manage schema evolution, and locate underlying data files. Iceberg catalogs such as Hive Metastore, AWS Glue, REST catalog, or Nessie provide the metadata services that allow Trino clusters to discover and query Iceberg datasets across distributed storage systems.

As a massively parallel SQL engine, Trino distributes query execution across many worker nodes, enabling interactive analytics on datasets that may contain billions of records. Analysts can filter large Iceberg tables by business dimensions, compute aggregations across massive transaction datasets, join multiple tables to enrich analysis, and power BI tools that query Iceberg tables using standard SQL. In this architecture, Iceberg manages the table structure and metadata while Trino provides the distributed execution engine that performs SQL analytics at scale.

Starburst builds on this ecosystem by providing platforms for running Trino-based analytics in production environments. Starburst refers to the combination of Apache Iceberg and Trino as the Icehouse architecture, where Iceberg serves as the open table format for the lakehouse data layer, and Trino provides the distributed SQL engine used to analyze those tables.

Starburst Enterprise and Starburst Galaxy package this architecture into production-ready platforms. Starburst Enterprise offers an enterprise distribution of Trino for self-managed or hybrid deployments, while Starburst Galaxy provides a fully managed cloud service for lakehouse analytics. Starburst Galaxy extends the Icehouse model with managed Iceberg ingestion, automated table maintenance such as compaction and optimization, and performance enhancements, including Warp Speed query acceleration. In this architecture, Iceberg becomes the shared analytical data layer on which large-scale SQL analytics can run efficiently.

Graph Analytics on Iceberg Data with PuppyGraph

While SQL analytics provides powerful tools for aggregating and exploring large datasets, some analytical questions focus on the relationships between entities rather than individual records. In financial systems, for example, investigators may need to trace how funds move across chains of accounts, identify groups of entities connected through transactions, or follow transaction paths that may indicate suspicious activity. Graph query languages, such as openCypher or Gremlin, provide a natural way to explore relationships within connected data. Traditionally, performing graph analytics requires loading data into a dedicated graph database through ETL pipelines, which introduces additional data movement and requires maintaining separate systems. PuppyGraph takes a different approach. 

Like Trino for SQL analytics, PuppyGraph is a distributed query engine designed for graph workloads. It allows graph models to be defined directly on top of relational data using metadata-driven schemas and executes graph queries on the underlying data without copying it into a separate system. This eliminates the need to build and maintain ETL pipelines, reduces system complexity, and allows graph queries to run on up-to-date data while leveraging existing data access controls. Because graph schemas are defined through metadata, multiple graph views can be created on the same underlying data, and models can be updated quickly without rebuilding data pipelines.

This approach fits naturally into lakehouse architectures. When working with Apache Iceberg, Trino, and Starburst platforms, PuppyGraph can access Iceberg data either directly through the catalog or indirectly through SQL engines such as Trino or Starburst that already expose the data for analytics. In both cases, graph queries operate on the same Iceberg data used for SQL analytics. This allows organizations to combine large-scale aggregation with relationship-oriented analysis under a unified data layer, without duplicating data across systems.

Architecture: SQL and Graph Analytics on Apache Iceberg

The following architecture shows how SQL and graph analytics operate on the same Apache Iceberg data within a lakehouse environment.

Figure: SQL and graph analytics on Apache Iceberg using Trino, Starburst, and PuppyGraph.

At the core of the architecture is Apache Iceberg, which defines the table layer on top of object storage systems such as S3, GCS, ADLS, or MinIO. Iceberg provides a consistent table abstraction and metadata layer, allowing different query engines to access the same data through a unified interface.

Trino and Starburst form the SQL query layer. Through their connector framework and Iceberg integration, they access Iceberg tables via the Iceberg API and execute distributed SQL queries for large-scale analytics. This combination of Trino and Apache Iceberg represents the Starburst Icehouse architecture, an open lakehouse design for running SQL analytics on Iceberg tables. 

PuppyGraph operates as the graph query layer on the same data. It supports two complementary access paths. PuppyGraph can connect directly to Iceberg through the catalog and Iceberg API, allowing graph queries to run on the underlying data. It can also connect to Trino or Starburst through the JDBC driver, reusing the same access path already established for SQL analytics while leveraging their existing Iceberg integration and execution capabilities. In both cases, PuppyGraph defines graph schemas that map relational tables into graph structures such as vertices and edges.

At the top layer, clients can interact with both SQL and graph query engines. This allows applications, analysts, and investigators to combine SQL analytics and graph analytics on the same Iceberg data without data duplication.

Demo: SQL and Graph Analytics on Financial Data

Let’s look at a demo. The full code and details are available in GitHub.

In this example, we use synthetic financial data inspired by the LDBC Financial Benchmark. The data is stored in Apache Iceberg tables backed by MinIO object storage. Trino provides the SQL query layer for large-scale OLAP analysis, while PuppyGraph enables graph analytics on the same datasets.

The dataset includes entities such as persons, accounts, companies, and loans, along with transactions and ownership relationships between them. Together they form a network of financial interactions that can be analyzed using both SQL queries and graph queries.

SQL Analytics with Trino

We start with SQL analytics to examine macro-level patterns in transaction activity. Analysts often begin with aggregate queries that summarize large volumes of financial data to identify trends or unusual behavior.

In this example, we analyze the volume of fund outflows across different account types during 2022. By joining the account and transfer tables and aggregating the results by account type, analysts can compute metrics such as:

• The number of active accounts
• The total number of transactions
• Total transfer volume
• Average transfer amount
• Maximum transfer amount
  

These metrics provide a macro-level view of how funds move across the system, and help identify which categories of accounts generate the largest transaction volumes.

Graph Analytics with PuppyGraph

Next, we analyze the same dataset using graph queries.

In this example, we start from a specific person and trace how funds flow through multiple account transfers. The analysis follows transfer paths of up to three hops within 2022, focusing on transactions where each transfer amount exceeds one million. It then examines whether the destination accounts receive loan deposits that meet the same criteria.

The query and visualization below illustrate the transfer and loan relationships identified by the graph query. You can click on vertices and edges to view details, or use the zoom functions to navigate the canvas.

MATCH p = (person:Person)-[edge1:PersonOwnAccount]->(account:Account)
          <-[edge2:AccountTransferAccount*1..3]-(other:Account)
          <-[edge3:LoanDepositAccount]-(loan:Loan)
WHERE elementId(person) = "Person[21990232556146]"
  AND ALL(e in edge2
      WHERE datetime("2022-01-01") < e.createTime < datetime("2023-01-01")
        AND e.amount >= 1000000)
  AND edge3.amount >= 1000000
  AND datetime("2022-01-01") < edge3.createTime < datetime("2023-01-01")
RETURN p

After identifying the transfer paths, we can further aggregate the results to measure how much loan funding ultimately flows into each destination account.

Key Takeaways

SQL analytics and graph analytics address different types of analytical questions. SQL is well suited for aggregations and large scale reporting, while graph queries make it easier to explore relationships and trace how entities interact across complex networks.

By combining Trino or Starburst with PuppyGraph, both analytical approaches can operate on the same datasets without copying data into a separate graph database.

Key benefits of this architecture include:

• Unified data access through Trino or Starburst connectors across data lakes, lakehouses, and warehouses
• Flexible graph modeling in PuppyGraph using catalogs that map relational tables into graph structures
• Complementary analytics workflows that move from SQL aggregation to graph based relationship exploration on the same data

Try the demo yourself using the GitHub repository above and explore how SQL and graph analytics can work together on the same data.