Datasette traces into Parseable: what telemetry exposes

What was published

On 6 October 2026 Simon Willison wrote up how he ran Parseable locally and sent it OpenTelemetry traces from Datasette. He had seen Parseable in a Show HN post. It is an observability tool compatible with OpenTelemetry. The open-source version is written in Rust, licensed under the AGPL, and described as a single ~180MB binary. There is also an "Enterprise" edition with extra features and a cloud-hosted option.

The trace source is Datasette. Version 1.0a41 added OpenTelemetry support, credited to Alex Garcia. Willison used Codex to work out the setup and published the working patterns in a human-written TIL.

What a trace contains

Willison's screenshot shows one trace in the Parseable web app, running on localhost. The root span is a GET request to a service named datasette-local. The trace has 247 spans in total and lasts 40.9 ms. Most child spans are db.query and db.query.execute, ranging from about 55 µs to 6.11 ms.

The source does not discuss security. Our reading of the screenshot is that a single page load produces one span per database query. That is the detail developers want when diagnosing slow requests. It is also the detail a security team should expect to find in a trace store: request paths, and potentially query details, depending on what the instrumentation records.

Why this matters to security teams

Telemetry pipelines tend to be adopted by engineers and reviewed late. A fast local setup, like the one in the TIL, is how a proof of concept becomes a shared backend. These are the questions worth asking before that happens:

• What is recorded? Check whether span attributes include URLs with tokens or identifiers, or query text containing user data. Confirm this against your own instrumentation, not just the defaults.
• Where does it go? Parseable offers self-hosted and cloud-hosted modes. Sending traces to a hosted backend moves operational data to a third party, which matters for data-residency and processor obligations.
• Who can read it? A trace store often has weaker access control than the application it describes. Apply the same access review you give production logs.
• How long is it kept? Retention should be set deliberately, not left at whatever the platform defaults to.
• What does the licence mean? The open-source build is AGPL. Legal review should look at this before the tool is embedded in or exposed alongside your own services.

A pragmatic approach

Start with a local or internal, self-hosted backend, as the TIL does, and keep it off the public internet. Review a sample of real traces for sensitive fields before you widen access. If you move to a hosted option, treat it as a new supplier in your third-party risk process. Parseable is new, so evaluate its authentication, authorisation and update model yourself rather than assuming them.

Nothing in the source reports a vulnerability in Parseable or Datasette. The point is narrower: lowering the cost of collecting traces raises the importance of governing what they contain.