Solana SQL Tutorial: How to Query Solana Data on Dune (2026)

To query Solana data with SQL, you write standard SQL on Dune against its Solana tables: solana.blocks for chain activity, gas_solana.fees for fees, tokens_solana.transfers for token movements and dex_solana.trades for swaps. The syntax is the same SQL you already know. What changes is the data model: vote transactions, lamports, base58 addresses, mints instead of symbols and two kinds of SOL.

This Solana SQL tutorial walks through five queries in the order you should learn them, from summing block counters to ranking DEX pairs. Each one is a real exercise from the WizardCamp Solana path, with the actual question, the reference solution, the real result and the Dune version you can run on the full table. Every query also hides one Solana specific trap, and that trap is the part worth remembering.

TL;DR:

• Where to query: Dune has free Solana tables. Start with solana.blocks, gas_solana.fees, tokens_solana.transfers, tokens_solana.fungible and dex_solana.trades.
• What is different from Ethereum: votes are counted as transactions (until October 21, 2026), fees are in lamports, addresses are base58 text, and a token is its mint address, not its symbol.
• The 5 queries: vote vs non-vote transactions, failed share, base vs priority fees, top tokens by transfers, top DEX pairs by volume.
• Since Alpenglow: vote transactions left Solana blocks on October 21, 2026, so any transactions per day chart needs a before and after split.
• Our data: Solana appears in 94 of 824 live roles (11%) on the Unchain Data job board, but in only 10 of 318 data roles (3%). Solana SQL is still a differentiator.

How do you query Solana data with SQL?

The easiest way to query Solana data with SQL is Dune: you write SQL in the browser against decoded Solana tables, and the free tier is enough to learn. Other options exist, such as Flipside, Allium, Goldsky pipelines or the Coinbase CDP SQL API, but Dune is the simplest place to start: a free tier, decoded Solana tables and a large library of public queries you can read and fork.

Dune's SQL engine, DuneSQL, is a fork of Trino. If you have already done our Dune SQL tutorial, you know the syntax. The rest of this guide is about the Solana data model.

Which Dune tables hold Solana data?

These are the Solana tables a beginner needs, and the ones the five queries below use.

Two habits save you time and credits on every one of them. Filter on the partition column first ("date" on solana.blocks, block_date elsewhere, plus block_month on dex_solana.trades), and start with one day before you run a week.

How Solana SQL differs from Ethereum SQL

• Slots are not block heights. A slot is a time box of about 200 ms (cut from 400 ms in stages that finished in October 2026), and a leader can skip it, so slot numbers have gaps. height counts produced blocks only.
• Votes were transactions. Until Alpenglow, validators voted by sending transactions, about half of the total. Any raw transaction count mixed consensus traffic with user activity.
• Fees are in lamports. 1 SOL is 1,000,000,000 lamports. Divide by 1e9, a decimal literal, so the result does not round to zero.
• Addresses are base58 text. There is no varbinary and no lower(hex(...)). You compare strings.
• A token is its mint address. Symbols are not unique, so you always join on token_mint_address.
• Wallets hold tokens through token accounts. One wallet can own many token accounts, and empty ones stay open. Our best SQL practice sites guide shows how that turns 3,188 token accounts into 76 real holders.

Coming from EVM, what tripped me up was the accounts model versus simple addresses, and inner instructions. Andrew Hong's A guide to Solana for Ethereum analysts is still the best EVM to Solana map I know, with a caveat: it is from November 2023. Slot times, vote transactions under Alpenglow, fee mechanics and some protocol counterparts have moved on, so verify any table or fee detail against current Dune docs before you lean on it. Core tables it points you to (solana.blocks, solana.instruction_calls, solana_utils.daily_balances) are still the right place to start.

Should you start with Solana or Ethereum?

It depends on what you want to analyze and which ecosystem you have affinity for. Ethereum and the broader EVM may have more job offers because the ecosystem is older and more mature. Solana may offer more opportunity because that is where the growth is, and there are fewer qualified analysts. Solana DeFi also has unique traits, like the rise of prop AMMs. If you want to analyze HFT, memecoins or pump.fun, go Solana, and not only for those. Solana SQL is a good differentiator either way.

How to use this tutorial

Run each query in WizardCamp, where it is graded instantly, then run the Dune version on the full table. WizardCamp runs on documented samples of real Dune tables in your browser. The samples cover August 24 to 30, 2026, so the numbers are real but describe the sample. Where the chain wide figure for the same week is known, it is given next to the sample result.

Query 1: Count vote and non-vote transactions per day

From WizardCamp's Chain Overview module ("Vote vs Non-Vote Transactions per Day", Solana path). Free.

SQL concept: SUM and GROUP BY on counters that already exist. Dune table: solana.blocks.

Each Solana block row carries counters for vote and non-vote transactions. For each day, return the total of each.

SELECT
  block_date,
  sum(total_vote_transactions) AS vote_transactions,
  sum(total_non_vote_transactions) AS non_vote_transactions
FROM blocks
GROUP BY block_date
ORDER BY block_date

The sample is 20 consecutive blocks per day, 140 blocks in total. It returns seven rows, from 13,523 vote and 28,123 non-vote transactions on August 24 to 12,749 and 16,752 on August 30. On three of the seven days (August 25, 27 and 29), votes outnumber non-votes.

On Dune, the same logic runs on the full table. The date column is called "date", in double quotes, because it collides with a type name:

SELECT
  "date" AS block_date,
  sum(total_vote_transactions) AS vote_transactions,
  sum(total_non_vote_transactions) AS non_vote_transactions
FROM solana.blocks
WHERE "date" BETWEEN DATE '2026-08-24' AND DATE '2026-08-30'
GROUP BY 1
ORDER BY 1

The lesson: you never scan a transaction table for this. The counters are already on the block, so this query is cheap even over months. Over the full week, the chain produced 1,185,589,798 vote and 1,220,162,525 non-vote transactions, so votes were 49.28% of everything. A transactions per day chart that does not split them out is half consensus traffic.

Solana SQL after Alpenglow

Solana's Alpenglow upgrade activated on mainnet at the start of epoch 1064, on October 21, 2026. Validators now send votes to each other and bundle them into certificates, so, as the Solana Foundation upgrade page puts it, vote transactions are no longer in blocks. Transaction counts and TPS dropped sharply that day, with no drop in user activity.

For your queries, that means three things:

1. Use non-vote transactions as your activity metric. It is the only series that means the same thing before and after October 21, 2026.
2. Re-baseline any chart that used total transactions. A long window that crosses October 21 shows a fake collapse.
3. Vote filters still run but filter nothing on new data. Historical data before the switch still contains votes.

Query 2: Compute the failed share of non-vote transactions

From WizardCamp's Chain Overview module ("Failed Share of Non-Vote Transactions", Solana path). Free.

SQL concept: a ratio of two sums, with nullif to avoid dividing by zero. Dune table: solana.blocks.

For each day, return failed transactions, non-vote transactions and failed transactions as a percent of non-vote transactions, to 2 decimals.

SELECT
  block_date,
  sum(failed_non_vote_transactions) AS failed_transactions,
  sum(total_non_vote_transactions) AS non_vote_transactions,
  round(100.0 * sum(failed_non_vote_transactions) / nullif(sum(total_non_vote_transactions), 0), 2) AS failed_share_pct
FROM blocks
GROUP BY block_date
ORDER BY block_date

On Dune, swap blocks for solana.blocks and block_date for "date", with the same date filter as Query 1:

SELECT
  "date" AS block_date,
  sum(failed_non_vote_transactions) AS failed_transactions,
  sum(total_non_vote_transactions) AS non_vote_transactions,
  round(100.0 * sum(failed_non_vote_transactions) / nullif(sum(total_non_vote_transactions), 0), 2) AS failed_share_pct
FROM solana.blocks
WHERE "date" BETWEEN DATE '2026-08-24' AND DATE '2026-08-30'
GROUP BY 1
ORDER BY 1

The lesson: the denominator decides the answer. Over the whole sample, failures are 44.16% of non-vote transactions but only 25.25% of all transactions, a gap of almost 19 points, because votes dilute the rate and the block has no counter for failed votes. Aggregate first, then divide: averaging a per block percentage gives a different number. Across the full chain that week, the failed share was 39.94%, in a narrow daily band of 38.63% to 42.35%. The sample swings wider because it is 20 blocks a day, which is sampling noise, not a different chain.

Query 3: Split daily fees into base and priority

From WizardCamp's Chain Overview module ("Daily Fees, Base vs Priority", Solana path).

SQL concept: column arithmetic and unit conversion. Dune table: gas_solana.fees.

Split each day's fees into the base fee and the priority fee, in lamports and in SOL.

SELECT
  block_date,
  sum(base_fee_raw) AS base_fee_lamports,
  sum(tx_fee_raw - base_fee_raw) AS priority_fee_lamports,
  sum(base_fee_raw) / 1e9 AS base_fee_sol,
  sum(tx_fee_raw - base_fee_raw) / 1e9 AS priority_fee_sol
FROM fees
GROUP BY block_date
ORDER BY block_date

The sample is 20 transactions per day. Across the week it holds 830,000 lamports of base fee and 6,261,210 lamports of priority fee (0.00626121 SOL), so priority is 88% of the total. One day dominates: on August 29, 20 transactions paid 5,716,806 lamports of priority fee against 110,000 of base fee.

On Dune, the fee split lives in a map column:

SELECT
  block_date,
  sum(tx_fee_breakdown_raw['base_fee']) AS base_fee_lamports,
  sum(tx_fee_raw - tx_fee_breakdown_raw['base_fee']) AS priority_fee_lamports,
  sum(tx_fee_breakdown_raw['base_fee']) / 1e9 AS base_fee_sol,
  sum(tx_fee_raw - tx_fee_breakdown_raw['base_fee']) / 1e9 AS priority_fee_sol
FROM gas_solana.fees
WHERE block_date = DATE '2026-08-24'
GROUP BY 1

The lesson: do not trust the ready made priority column. Dune derives prioritization_fee_raw from the requested compute limit, which is unreliable: in the sample it disagrees with the real remainder on 72 of 140 rows and sums to a negative total. Take the priority fee as tx_fee_raw - base_fee_raw, which is exact because the base fee is always 5,000 lamports per signature. On the full chain that week, base fees were 804 to 1,058 SOL a day and priority fees 4,879 to 8,988 SOL a day, so priority was 86% to 90% of all fees. On Solana, the fee market is the priority fee.

Query 4: Rank tokens by transfer count

From WizardCamp's SPL Tokens and the Accounts Model module ("Top Tokens by Transfer Count", Solana path).

SQL concept: aggregate, then JOIN for the label, then LIMIT. Dune tables: tokens_solana.transfers and tokens_solana.fungible.

Rank tokens by how often they moved over the seven days and return the top 10 with their symbol.

SELECT
  f.symbol,
  t.token_mint_address,
  sum(t.transfers) AS transfers
FROM token_transfers_7d t
JOIN fungible_tokens f ON f.token_mint_address = t.token_mint_address
GROUP BY f.symbol, t.token_mint_address
ORDER BY transfers DESC
LIMIT 10

The other five in the top 10 are cfUSD, a pump.fun token whose symbol is a full advertising sentence, USD1, cbBTC and ANTFUN.

On Dune, tokens_solana.transfers is about 34 TB, so filter on block_date and test on one day first:

WITH t AS (
  SELECT token_mint_address, count(*) AS transfers
  FROM tokens_solana.transfers
  WHERE block_date = DATE '2026-08-24'
  GROUP BY 1
)
SELECT f.symbol, t.token_mint_address, t.transfers
FROM t
LEFT JOIN tokens_solana.fungible f ON f.token_mint_address = t.token_mint_address
ORDER BY t.transfers DESC
LIMIT 10

The lesson: join on the mint address, never the symbol. In this dataset, 16 of the 100 symbols belong to more than one mint, so a join on symbol fans out and inflates the counts, and symbols can be padded or full of spam. Also look at the top two rows: native SOL (So111...111) and wrapped SOL (So111...112) are the same asset under two mints. Together they account for about 1.18 billion of the roughly 1.83 billion token transfers the chain recorded that week. Decide up front whether your report treats them as one asset, and never mix them silently with application tokens.

Query 5: Find the top DEX pairs by volume

From WizardCamp's DEXs, Venues and Volume module ("Top Pairs by Volume", Solana path).

SQL concept: ORDER BY with a tiebreaker and LIMIT. Dune table: dex_solana.trades.

Rank token pairs by USD volume over the week and return the top 10, with trade counts and volume rounded to 2 decimals.

SELECT
  token_pair,
  trades,
  round(usd_volume, 2) AS usd_volume
FROM dex_top_pairs
ORDER BY usd_volume DESC, token_pair
LIMIT 10

The rest of the top 10 are WSOL-fone, USDC-TRUMP, USDC-USD1, WSOL-USD1 and WSOL-CATE.

On Dune, build the aggregate yourself from the trades table:

SELECT
  token_pair,
  count(*) AS trades,
  round(sum(amount_usd), 2) AS usd_volume
FROM dex_solana.trades
WHERE block_month = DATE '2026-08-01'
  AND block_date BETWEEN DATE '2026-08-24' AND DATE '2026-08-30'
GROUP BY 1
ORDER BY usd_volume DESC NULLS LAST, token_pair
LIMIT 10

The lesson: one pair is almost half the market. On a full Dune run for that week (validated November 9, 2026), WSOL-USDC did about $6.83 billion, 45% of the $15.21 billion traded across the top 200 pairs. Note that the pair is WSOL, not SOL: DEXs trade the wrapped token. And amount_usd is not always filled in. Across the week, 0.370% of trades had no USD price, and on some venues the share was much higher, so SUM quietly skips them. Count the nulls before you publish a volume number.

The 5 Solana SQL patterns at a glance

Is Solana SQL worth learning for a crypto data job?

Yes, because few candidates show it. As of November 8, 2026, the Unchain Data job board lists 824 live roles. 94 of them (11%) mention Solana, at 63 companies. But among the 318 live data roles (analyst, engineer, scientist, head of data, research and compliance analyst), only 10 (3%) mention Solana, at 7 companies: Coinbase, Dune (four roles), Everstake, FMR, Mercuryo, RockawayX and Visa. Meanwhile 193 of those 318 data roles (61%) mention SQL.

Read that as an opportunity: Solana is everywhere in the industry, but data teams rarely ask for it by name, so a public Solana dashboard or a finished Solana SQL path sets you apart from candidates who only know Ethereum. You can browse the live roles on the Web3 data analyst job board.

What to learn after these 5 queries

1. Holders and balances. Count holders correctly with token accounts, covered in crypto data analyst interview questions.
2. Users and retention. The new vs returning traders exercise in our best SQL practice sites guide shows the first seen pattern on dex_solana.trades.
3. Aggregators, memecoins, lending and staking. These are modules 4 to 8 of the WizardCamp Solana path: Jupiter routing, pump.fun launches and graduation, liquidations, validators and MEV.
4. The pipeline side. If you want to build Solana data pipelines rather than query them, read How to Become a Crypto Data Engineer and our blockchain data engineering guide.
5. The career side. How to Become a Crypto Data Analyst covers portfolios and where to apply.

The WizardCamp Solana path has 78 graded exercises across 8 modules, from Chain Overview to NFTs and Compressed Assets, all on samples of real Dune tables. For the Ethereum side, the Dune SQL tutorial covers ten more queries, and Learn Onchain SQL: Inside WizardCamp shows how the course works.

Frequently Asked Questions

Can you query Solana with SQL?

Yes. Dune, Flipside, Allium and other platforms index Solana into SQL tables, so you can query blocks, transactions, token transfers and DEX trades with standard SQL. Dune is the easiest place to start because it has a free tier and public Solana queries you can read and fork.

What are the main Dune Solana tables?

Start with solana.blocks for chain activity, solana.transactions and solana.instruction_calls for transaction and program detail, gas_solana.fees for fees, tokens_solana.transfers with tokens_solana.fungible for tokens, solana_utils.daily_balances for balances and dex_solana.trades for swaps.

How is Solana SQL different from Ethereum SQL?

The SQL is the same. The data is different: slots skip, fees are in lamports (1 SOL is 1e9 lamports), addresses are base58 text instead of hex, wallets hold tokens through separate token accounts, symbols are not unique, and native SOL and wrapped SOL are two mints. Before October 21, 2026, about half of Solana transactions were validator votes.

How did Alpenglow change Solana data?

Since Alpenglow activated on October 21, 2026, validator votes are no longer transactions in blocks. Total transaction counts and TPS dropped sharply while user activity did not. Use non-vote transactions as your activity metric, and re-baseline any chart that crosses that date.

How long does it take to learn Solana SQL?

If you know basic SQL, you can write the five queries in this tutorial in one or two sessions. The full WizardCamp Solana path is 78 exercises and 20+ hours. If you are new to SQL, start with WizardCamp's free SQL Foundations module, then the free first exercises of the Solana path.

Should I start with Solana or Ethereum SQL?

It depends on what you want to analyze and which ecosystem you have affinity for. Ethereum and the broader EVM may have more job offers because the ecosystem is older and more mature. Solana may offer more opportunity because growth is there and there are fewer qualified analysts. Solana DeFi has unique traits like prop AMMs, and if your focus is HFT, memecoins or pump.fun, start with Solana. Either way, Solana SQL is a useful differentiator.

Key Takeaways

• Solana SQL is standard SQL on Dune's Solana tables. The traps are in the data model, not the syntax.
• Split votes out. Votes were 49.28% of transactions in our sample week, and they left blocks with Alpenglow on October 21, 2026.
• Divide by the right denominator. The failed share is 44% of non-vote transactions in the sample, but 25% if you wrongly include votes.
• Derive the priority fee as tx_fee_raw - base_fee_raw, and divide by 1e9 for SOL.
• Join on the mint, never the symbol, and decide how to treat native SOL and wrapped SOL.
• Solana SQL is a differentiator. 11% of live roles on the Unchain Data job board mention Solana, but only 3% of data roles do.

Practice Solana SQL on WizardCamp for free →