HyperliquidRPCDocs
Historical

Database access

For teams whose analytics outgrow request/response: a scoped, read-only account on the archive database itself. Point your own notebooks, BI tools, and schedulers at the tables behind the query API and run sustained workloads without an HTTP hop per query.

Account model

  • Read-only by construction. The role can SELECT from the archive tables and nothing else: no writes, no DDL, no access to anything outside the datasets in your plan.
  • Scoped per team. Credentials are issued per organization, separate from your API keys; a leaked database password never exposes your stream or RPC access, and vice versa.
  • Rotated on request. Ask and we reissue the secret; the old one is revoked immediately. Rotation does not interrupt API-key products.
  • Provisioned, not self-serve. Database access is enabled per account. Request it from the console or via contact.

Connecting

Connection details are issued privately with your account. We do not publish database hostnames or ports. Treat them like the secret they ship with.

connection details (placeholders)yaml
# issued privately with your account (database hosts are never public)host:     <assigned-host>port:     <assigned-port>        # TLS requireduser:     <team>_ro              # read-only rolepassword: <issued-secret>database: hyperliquid

The server speaks the same ClickHouse-style SQL dialect as the query API (toStartOfMinute, argMin/argMax, countIf), so any ClickHouse-compatible client or driver your stack already uses will connect with the issued parameters. TLS is required; plaintext connections are refused.

First query

Verify the account with something cheap: top markets by volume over the last day.

SELECT coin, count() fills, sum(notional) volumeFROM tradesWHERE block_time > now() - 86400GROUP BY coinORDER BY volume DESCLIMIT 10

Tables and columns match Schemas exactly. What you see over the wire is what sits in the database.

Query etiquette and limits

You are querying the same archive that serves every customer; accounts come with concurrency and runtime ceilings sized to your plan, and queries that ignore the basics below will hit them first.

  • Filter time first. Every table is organized by block_time; an unbounded scan of book_updates (1B+ rows) or orders (1.65B+ events) is the canonical way to get a query terminated.
  • Name your columns. SELECT * on wide event tables drags every attribution field through the wire; select what you aggregate.
  • Aggregate close to the data. Push GROUP BY and countIf-style conditions into the query rather than pulling raw rows into pandas to reduce them.
  • Long-running queries may be killed. Runtime ceilings apply per plan; break backfills into date-bounded chunks that finish in minutes, not hours.
  • Bulk pulls belong in exports. If the result set is "most of a dataset", use bulk exports. Parquet in your bucket beats streaming millions of rows through a SQL connection.

Which historical surface to use

You wantUse
An answer to a question, occasionallyquery API
Sustained interactive analytics, BI, schedulersdatabase access
Whole datasets or date ranges as filesbulk exports
A short backfill straight into your consumerstream replay

All four read the same archive with the same schema. Choose by access pattern, not by data availability.