​

Migrating from Flipside to Dune

With the recent shutdown of Flipside Crypto, we extend a warm welcome to all Flipside users exploring Dune. We understand that migrating your queries and workflows can be a challenging task. This guide is designed to help you transition smoothly by mapping Flipside’s data tables to Dune’s and highlighting the key differences between their respective SQL query engines.

Dune offers a powerful platform for blockchain analytics, powered by a community of thousands of creators. We’re excited to have you join us!

​

Key Differences at a Glance

For a quick overview, here are some of the main differences between the Flipside and Dune platforms:

​

Table Mappings: Flipside to Dune

Below is a comprehensive mapping of Flipside’s tables to their Dune equivalents. We’ve done our best to find the closest match. In Dune, data is often more modular, so a single Flipside table might map to multiple Dune tables or require a JOIN operation to achieve the same result. Use the search bar in Dune’s data explorer to find these tables.

​

Migrating Queries: From Snowflake to Dune SQL (Trino)

The most significant adjustment you’ll make when migrating from Flipside is the query engine. Flipside utilized Snowflake’s SQL dialect, whereas Dune is powered by Dune SQL, which is based on Trino (formerly PrestoSQL). While both are standards-compliant, Trino has its own flavor and functions that differ from Snowflake.

Let’s walk through the most common changes you’ll need to make to your queries.

​

1. The 0x Prefix and Byte Arrays: A Critical Difference

In Dune, blockchain addresses, transaction hashes, and other raw byte data are stored as VARBINARY types, not simple strings. When you filter by or insert these values in your queries, you must prefix them with 0x. This is one of the most common tripping points for new users.

Dune SQL (Correct):

-- Filtering for transactions to a specific address
SELECT *
FROM ethereum.transactions
WHERE "to" = 0x742d35Cc6634C0532925a3b844Bc454e4438f44e -- Uniswap V2: Router 2

Flipside/Snowflake (and incorrect in Dune):

-- This will fail or return no results in Dune
SELECT *
FROM ethereum.transactions
WHERE "to" = '0x742d35Cc6634C0532925a3b844Bc454e4438f44e'

​

2. Common Syntax Adjustments

Here are some of the most frequent syntax adjustments you’ll encounter.

​

Identifier Quoting

This should be an easy transition. Both Snowflake and Trino follow the ANSI SQL standard and use double quotes (") to quote identifiers (e.g., column names with spaces or reserved words like "from" or "to"). Your quoting syntax will likely not need to change.

• Snowflake/Dune SQL (Trino): SELECT "from", "to" FROM "my_table";

​

Data Type Casting

Snowflake commonly uses :: for casting. Dune SQL uses the ANSI SQL standard CAST(column AS TYPE).

• Snowflake: SELECT '123'::integer, '2023-01-01'::date;
• Dune SQL: SELECT CAST('123' AS integer), CAST('2023-01-01' AS date);

​

Accessing JSON Data

Accessing nested data in JSON objects requires specific functions in Trino. While Snowflake uses a colon (:), Trino uses json_extract_scalar.

• Snowflake: SELECT my_json_column:key::string FROM my_table;
• Dune SQL (Trino): SELECT json_extract_scalar(my_json_column, '$.key') FROM my_table;

​

3. Key Function and Pattern Changes

​

Flattening Arrays with UNNEST

To un-nest array elements into their own rows, Snowflake uses LATERAL FLATTEN(). The Trino equivalent is UNNEST.

Snowflake:

SELECT t.id, value:name::string
FROM my_table t,
LATERAL FLATTEN(input => t.my_json_array);

Dune SQL (Trino):

SELECT t.id, item.name
FROM my_table t
CROSS JOIN UNNEST(t.my_json_array) AS t(item)

​

Filtering Window Functions (Replacing QUALIFY)

Snowflake’s QUALIFY clause is a convenient way to filter the results of a window function. QUALIFY is not available in Dune SQL. The standard approach is to use a subquery or a Common Table Expression (CTE), which works perfectly in Trino.

Snowflake:

SELECT *
FROM my_table
QUALIFY ROW_NUMBER() OVER (PARTITION BY id ORDER BY timestamp DESC) = 1;

Dune SQL (Trino):

WITH ranked_rows AS (
    SELECT *,
        ROW_NUMBER() OVER (PARTITION BY id ORDER BY timestamp DESC) as rn
    FROM my_table
)
SELECT * FROM ranked_rows
WHERE rn = 1;

​

4. Common Migration Examples

Here are some practical examples of migrating common Flipside query patterns to Dune:

​

Example 1: Daily DEX Volume Analysis

Flipside Pattern:

SELECT 
    block_timestamp::date as date,
    SUM(amount_usd) as volume_usd
FROM ethereum.core.ez_dex_swaps
WHERE block_timestamp >= '2024-01-01'::date
GROUP BY 1
ORDER BY 1;

Dune Equivalent:

SELECT 
    DATE_TRUNC('day', block_time) as date,
    SUM(amount_usd) as volume_usd
FROM dex.trades
WHERE block_time >= CAST('2024-01-01' AS date)
    AND blockchain = 'ethereum'
GROUP BY 1
ORDER BY 1;

​

Example 2: Token Balance Analysis

Flipside Pattern:

SELECT 
    user_address,
    symbol,
    current_bal
FROM ethereum.core.ez_current_balances
WHERE contract_address = '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48'::string;

Dune Equivalent:

SELECT 
    address as user_address,
    symbol,
    amount_raw / POW(10, decimals) as current_bal
FROM balances_ethereum.erc20_latest
WHERE contract_address = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48; -- USDC

​

5. Query Performance Tips

Many Flipside tables encouraged filtering by block_timestamp::date for performance. In Dune, many raw and curated tables are physically partitioned by date-based columns (like block_day or block_time). Always add a filter on these partitioned columns where available, as it can dramatically speed up your queries by reducing the amount of data scanned.

You can find partition keys in the schema browser in the query editor.

Performance Best Practices:

• Always filter by block_time or block_date when available
• Use the curated Spells (like dex.trades, nft.trades) instead of raw tables when possible
• Limit your date ranges to what you actually need for analysis
• Use LIMIT clauses during development to avoid scanning large datasets

​

Understanding Dune’s Data Platform

Dune’s approach to data is layered, providing different levels of abstraction to make analysis easier:

1. Raw Data: Raw, unprocessed data from the blockchain (e.g., ethereum.blocks, ethereum.transactions). This is your source of truth.
2. Decoded Data: Raw data is decoded into human-readable tables. For example, contract events are decoded into tables like aave_v3_ethereum.Supply. This saves you the effort of dealing with logs and topics.
3. Curated Data (Spells): These are higher-level abstractions built and maintained by the community. Tables like dex.trades or nft.trades aggregate data across multiple protocols, making cross-platform analysis simple.

We encourage you to explore the data catalog in the Dune app to discover the wealth of datasets available.

​

Common Migration Challenges and Solutions

​

Challenge 1: Missing Convenience Tables

Issue: Flipside provided many “EZ_” convenience tables that aggregated complex data. Solution: Dune’s curated Spells (like dex.trades, nft.trades) often provide even better aggregations. If a specific convenience table doesn’t exist, you can often recreate it using raw or decoded data.

​

Challenge 2: Different Table Schemas

Issue: Column names and data types may differ between platforms. Solution: Use Dune’s data explorer to examine table schemas. The DESCRIBE command can also help: DESCRIBE dex.trades;

​

Challenge 3: Cross-Chain Analysis

Issue: Flipside often had separate databases per chain. Solution: Dune’s curated tables often include a blockchain column, making cross-chain analysis much easier. Simply add WHERE blockchain IN ('ethereum', 'polygon') to your queries.

​

Need More Help?

We know migrating can be tough, but you’re not alone. Here are some resources to help you on your journey:

• Dune Documentation: docs.dune.com
• Dune Discord: Join our Discord server to ask questions and connect with thousands of other crypto data wizards.
• Find a Query: Fork one of the 600,000+ public queries on Dune to get a head start.
• Data Catalog: Explore our comprehensive data catalog to understand available datasets.
• Query Examples: Check out our quickstart guide for hands-on examples.
• **Onboarding: **Fill out this onboarding form and we’ll schedule a live session to help you.

Welcome to Dune! We can’t wait to see what you build.