Point it at any Apache Arrow Flight SQL server and it reads back
what the server supports, what's in it, and the live wire anatomy of a query —
sparrow doctor, in a web page. Runs on sparrowJS over gRPC-web;
credentials stay in your browser.
try:
Ready. Pick a server above, or paste any gRPC-web Flight SQL endpoint.
A browser can reach a Flight server only through a gRPC-web proxy (Envoy /
Traefik) with CORS open — the three presets are proxied on this host. The connection layer
below the app (DNS, TCP, TLS handshake) is out of a browser's reach by design; that's what
the CLI'ssparrow doctor covers. This page is the read-only
surface — doctor --server + orient + sql --stats — that
the browser can do, from the same one engine.
conformance card
catalog
query & wire anatomy
connection layer deep probe · sparrow doctor, server-side
A browser has no raw sockets, so everything above
is the app layer. To see underneath — DNS, TCP, the TLS handshake and certificate —
this runs the real sparrow doctor on the server and reports back. Give it the
raw grpc/grpc+tls endpoint (the Flight port itself, not the
gRPC-web URL above — they're different transports). It's anonymous: no credentials, it
stops honestly at the auth layer. Each layer is timed (see where the milliseconds go —
DNS vs TCP vs the TLS handshake), with a bare-TCP latency read from sparrow ping.
Public endpoints only; it's rate-limited. Also a plain JSON API: GET /probe?endpoint=…
real servers in the wild:
The last three are other companies' production Flight SQL
endpoints — the same tool works on the whole ecosystem. Each resolves, connects, and shows its
real TLS certificate, then stops at auth (they want an API key). Nothing a TLS handshake check
wouldn't already reveal.
server
resolves
TLS certificate — real, live
stops at
Dremio Cloud
3 IPs
TLS 1.2 · *.aws.dremio.cloud · Amazon
🔒 Unauthenticated
Spice.ai
3 IPs
TLS 1.2 · *.spiceai.io · Amazon
🔒 "API key not found"
InfluxDB Cloud
1 IP
TLS 1.3 · …cloud2.influxdata.com · Let's Encrypt
🔒 Unauthenticated
Captured 2026-07-30 — a snapshot so you can read all three at a
glance without tripping the rate limit. Click any preset above to re-run it live (the cert,
IPs and expiry are read fresh each time).
how it's built
One diagnostic engine, drawn as two tiers around a
hard boundary: a browser has no raw sockets, so it can reach a Flight server only
through a gRPC-web proxy, and only for the application layer.
Tier 1 — in your browserno backend · credentials stay in the tab
sparrowJS (TypeScript, on npm, Apache-2.0) speaks
Flight SQL over gRPC-web — @connectrpc/connect-web → Envoy
grpc_web → the Flight server — and decodes Arrow with
apache-arrow. The card is capabilities() (decoded GetSqlInfo);
the catalog is tables()/schema(); the wire anatomy is the
stats on every query(). It even reads Utf8View
(transcoded client-side) and negotiates lz4 — all without a server of ours.
Tier 2 — server-side deep probethe layers a browser can't see
The connection layer (DNS, TCP, TLS) needs raw sockets, so the same Go CLI the
terminal runs — sparrow doctor -o json — runs on the VPS
behind a small guarded service, exposed as a plain JSON API:
GET /probe?endpoint=… (CORS-open). It's anonymous (no credentials, ever),
SSRF-guarded (every resolved IP must be globally routable — private / loopback /
link-local / metadata are refused), rate-limited, and a diagnostic, not a relay.
The same engine, four surfaces —
the decision that keeps them honest is a shared vocabulary, not shared code paths: