Skip to main content

​
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 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
  • REST API (programmatic): Yes, create free Client API keys

​
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 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 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 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? 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 — token transfers (including native SOL transfers) projected from transfer instructions
  • 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 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 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 to connect with our team and other developers.