> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cdp.coinbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SQL API FAQ

### What SQL features are supported?

CoinbaSeQL supports all standard SQL query features including SELECT statements, WHERE filtering, JOINs, aggregations (COUNT, SUM, AVG, MIN, MAX), subqueries, Common Table Expressions (CTEs), UNION operations, and CASE statements. See the [CoinbaSeQL reference](/data/sql-api/sql) for details.

### What's the difference between SQL API and Wallet History API?

* **SQL API**: Write custom SQL queries against any blockchain data (events, transactions, blocks, transfers). Flexible and powerful.
* **Wallet History API**: Pre-built endpoints for wallet-specific data. Simple and fast for common wallet operations.

Use SQL API when you need custom queries or data beyond wallet history. Use Wallet History API for simple wallet transaction and balance lookups.

### Do I need API keys?

* **SQL Playground** (browser): No API keys needed—just sign in to [CDP Portal](https://portal.cdp.coinbase.com/)
* **REST API** (programmatic): Yes, create free [Client API keys](https://portal.cdp.coinbase.com/api-keys/client)

### What are the query limits?

* **Maximum result set**: 50,000 rows
* **Query timeout**: 30 seconds
* **Maximum JOINs**: 12 per query
* **Query length**: 10,000 characters maximum
* **Rate limit**: 2 queries every second per project (default)

These limits apply across supported networks, including Base and Solana. See the [REST API reference](/api-reference/v2/rest-api/sql-api/run-sql-query) for the full list of query constraints.

### How do I optimize slow queries?

1. **Use indexed columns in WHERE clauses**: For example, when querying `base.events`, filter by `event_signature` and `address`. On Solana, filter `solana.transfers` by `mint` and `block_time`, or `solana.instructions` by `executing_account`, `instruction_name`, and `block_time`. Check the [schema](/data/sql-api/schema) of each table.
2. **Use specific block ranges**: Query smaller ranges by `block_timestamp` (Base) or `block_time` (Solana) rather than the entire history from genesis.
3. **Filter early**: Put selective filters in WHERE clauses.
4. **Avoid SELECT \***: Select only the columns you need.

### What happens if my query times out?

If your query exceeds the 30-second timeout, you'll receive a `timed_out` error. To fix:

* Filter by indexed columns (`event_signature` / `address` on Base; `mint` / `executing_account` / `instruction_name` on Solana) to remove irrelevant rows
* Reduce the block range in your WHERE clause via `block_timestamp` or `block_time`
* Simplify complex JOINs (avoid `OR` in JOINs)

### What networks are supported?

SQL API supports **Base Mainnet** (`base.*`), **Base Sepolia** (`base_sepolia.*`), and **Solana Mainnet** (`solana.*`). Tables are always prefixed with the network.

See the [schema reference](/data/sql-api/schema) for the full table list on each network. Solana currently exposes a smaller set of tables than Base. See [What data is available for Solana?](#what-data-is-available-for-solana) below.

### How fresh is the data?

* **Base Mainnet and Base Sepolia**: Data is typically **\< 250ms from chain tip**, with query response latency **\< 500ms**.
* **Solana Mainnet**: Data is typically available within a few seconds of chain tip (P99 freshness under 5 seconds).

### What data is available for Solana?

At launch, Solana coverage focuses on **SPL Token** and **Token-2022** activity through two tables:

* [`solana.transfers`](/data/sql-api/schema#solana-transfers) — token transfers (including native SOL transfers) projected from transfer instructions
* [`solana.instructions`](/data/sql-api/schema#solana-instructions) — decoded instruction calls for those programs

About **3 months** of history is available at launch. Coverage may evolve during public beta. See [Query Solana tokens](/data/sql-api/solana-tokens) for examples and limitations.

### What data types does SQL API support?

SQL API uses ClickHouse data types including:

* **Numeric**: UInt8, UInt16, UInt32, UInt64, UInt128, UInt256, Int8, Int16, Int32, Int64, Int128, Int256
* **String**: String
* **Boolean**: Bool
* **Temporal**: Date, DateTime, DateTime64
* **Complex**: Array, Map, Tuple

See the [schema reference](/data/sql-api/schema) for field-level type information.

### How do I handle re-orgs?

Each table includes an `action` field:

* `1` or `'added'`: Data was added to the chain
* `-1` or `'removed'`: Data was removed due to reorganization

To query only active (non-reorged) data, filter where the sum of actions is greater than 0, or simply filter for `action = 1` or `action = 'added'`. On Base, the `log_id` on each row can be used to identify duplicates. On Solana, use `instruction_id` as the stable identifier across reprocessing.

### Where can I get help?

Join **#onchain-data** in the [CDP Discord](https://discord.com/invite/cdp) to connect with our team and other developers.