An open source multi-tool for exploring and publishing data https://datasette.io
  • Python 79.4%
  • JavaScript 11.4%
  • HTML 6.2%
  • CSS 2.7%
  • Shell 0.1%
Find a file
Alex Garcia f5eada266e Give every span a request to belong to
Nothing in Datasette created a span for the HTTP request itself, so every
span the database layer emits was a root span. Measured on this branch: one
faceted table page produces 70 spans in 36 separate traces, none of which
carries a URL. A trace UI shows that as dozens of unrelated single-span
traces per page, interleaved across concurrent requests - worse than
?_trace=1 at the exact job people reach for tracing to do. With the request
span it is 71 spans in 1 trace.

`opentelemetry-instrument` does not fix this on its own: auto-instrumentation
only picks up frameworks that ship an instrumentor entry point, and
Datasette's raw ASGI app is not one.

TelemetryMiddleware is mounted outermost in Datasette.app(), after the
asgi_wrapper() plugin loop, so plugin middleware and the CSRF layer run
*inside* the span. Putting it in DatasetteRouter instead would leave a span
created by an instrumented plugin as an orphan root - reintroducing the
problem for exactly the code most likely to be instrumented.

It stays at ~90 lines, against roughly 700 for
opentelemetry-instrumentation-asgi, because Datasette's app does not return
before its body is sent: route_path awaits response.asgi_send(send), and a
streaming CSV export runs its generator inline inside AsgiStream.asgi_send.
So a plain `finally` covers the response body and no deferred-end machinery
is needed.

Two decisions worth flagging for review:

- Inbound W3C traceparent and baggage are extracted, using the *global*
  propagator. That is the ecosystem norm (Flask, Django, FastAPI, the ASGI
  instrumentation), and going through the global propagator leaves the
  operator in control with no Datasette setting to invent:
  OTEL_PROPAGATORS=none disables it entirely. A public instance that does
  not want client-influenced traces should strip those headers at the proxy.
- url.query is not recorded, anywhere. Datasette query strings carry
  user-supplied SQL in ?sql= and canned query parameters. client.address is
  not recorded either.

The status code is sniffed from the ASGI http.response.start message rather
than read off a Response, because asgi_static, the favicon route, AsgiStream
and AsgiFileDownload all send that message themselves and never build one.
Only a >= 500 sets an error status - per semantic conventions a 4xx is the
client's mistake, and Datasette 404s are routine enough that treating them
as errors would bury a real 500.

The registry gains a `dynamic` flag, because this span's name is composed at
runtime and so can never equal a fixed registry string. Dynamic entries
resolve by span kind instead, and only after exact and prefix matching has
failed, so they cannot shadow a span that does have a registered name.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-01 16:24:35 -07:00
.github check-latest: true, add 3.15 to test matrix, to test RCs (#2895) 2026-09-01 13:37:15 -07:00
datasette Give every span a request to belong to 2026-09-01 16:24:35 -07:00
demos Fixed an unnecessary f-string 2024-02-04 10:15:21 -08:00
docs Give every span a request to belong to 2026-09-01 16:24:35 -07:00
tests Give every span a request to belong to 2026-09-01 16:24:35 -07:00
.coveragerc Configure code coverage, refs #841, #843 2020-06-13 13:48:23 -07:00
.dockerignore Build Dockerfile with SpatiaLite 5, refs #1249 2021-03-26 21:27:40 -07:00
.git-blame-ignore-revs Ignore Black commits in git blame, refs #1716 2022-04-22 14:58:46 -07:00
.gitattributes New explicit versioning mechanism 2020-10-28 20:38:15 -07:00
.gitignore Ignore ignored/ directory 2026-06-25 21:20:29 -07:00
.isort.cfg Used isort to re-order my imports 2018-05-14 00:04:23 -03:00
.prettierrc .prettierrc, refs #1166 2020-12-31 13:25:44 -08:00
.readthedocs.yaml dependency-groups and uv (#2611) 2025-12-11 17:32:58 -08:00
CODE_OF_CONDUCT.md Add code of conduct again 2022-03-15 08:38:42 -07:00
codecov.yml codecov should not be blocking 2020-07-02 21:29:32 -07:00
Dockerfile Upgrade Docker images to Python 3.11, closes #1853 2022-10-25 12:04:53 -07:00
Justfile Add Prettier check to lint recipe (#2821) 2026-07-03 09:50:35 -07:00
LICENSE Initial commit 2017-10-22 17:39:03 -07:00
MANIFEST.in Include LICENSE in sdist (#1043) 2020-10-23 13:54:34 -07:00
package-lock.json Bump rollup from 3.29.5 to 3.30.0 (#2651) 2026-03-30 10:54:48 -07:00
package.json Bump rollup from 3.29.5 to 3.30.0 (#2651) 2026-03-30 10:54:48 -07:00
pyproject.toml Add opentelemetry-api dependency and datasette/telemetry.py scaffolding 2026-09-01 16:24:15 -07:00
pytest.ini Initial Playwright setup plus first test 2026-06-14 16:39:55 -07:00
README.md Replace Glitch with Codespaces, closes #2488 2025-05-28 19:17:22 -07:00
ruff.toml Upgrade to ruff>=0.16.0 (#2857) 2026-07-25 15:47:08 -07:00
setup.cfg Switch to ruff and fix all lint errors, refs #2630 2026-01-23 20:43:16 -08:00
test-in-pyodide-with-shot-scraper.sh Test against pyodide/v314.0.0 2026-06-22 10:11:56 -07:00

Datasette

PyPI Changelog Python 3.x Tests Documentation Status License docker: datasette discord

An open source multi-tool for exploring and publishing data

Datasette is a tool for exploring and publishing data. It helps people take data of any shape or size and publish that as an interactive, explorable website and accompanying API.

Datasette is aimed at data journalists, museum curators, archivists, local governments, scientists, researchers and anyone else who has data that they wish to share with the world.

Explore a demo, watch a video about the project or try it out on GitHub Codespaces.

Want to stay up-to-date with the project? Subscribe to the Datasette newsletter for tips, tricks and news on what's new in the Datasette ecosystem.

Installation

If you are on a Mac, Homebrew is the easiest way to install Datasette:

brew install datasette

You can also install it using pip or pipx:

pip install datasette

Datasette requires Python 3.8 or higher. We also have detailed installation instructions covering other options such as Docker.

Basic usage

datasette serve path/to/database.db

This will start a web server on port 8001 - visit http://localhost:8001/ to access the web interface.

serve is the default subcommand, you can omit it if you like.

Use Chrome on OS X? You can run datasette against your browser history like so:

 datasette ~/Library/Application\ Support/Google/Chrome/Default/History --nolock

Now visiting http://localhost:8001/History/downloads will show you a web interface to browse your downloads data:

Downloads table rendered by datasette

metadata.json

If you want to include licensing and source information in the generated datasette website you can do so using a JSON file that looks something like this:

{
    "title": "Five Thirty Eight",
    "license": "CC Attribution 4.0 License",
    "license_url": "http://creativecommons.org/licenses/by/4.0/",
    "source": "fivethirtyeight/data on GitHub",
    "source_url": "https://github.com/fivethirtyeight/data"
}

Save this in metadata.json and run Datasette like so:

datasette serve fivethirtyeight.db -m metadata.json

The license and source information will be displayed on the index page and in the footer. They will also be included in the JSON produced by the API.

datasette publish

If you have Heroku or Google Cloud Run configured, Datasette can deploy one or more SQLite databases to the internet with a single command:

datasette publish heroku database.db

Or:

datasette publish cloudrun database.db

This will create a docker image containing both the datasette application and the specified SQLite database files. It will then deploy that image to Heroku or Cloud Run and give you a URL to access the resulting website and API.

See Publishing data in the documentation for more details.

Datasette Lite

Datasette Lite is Datasette packaged using WebAssembly so that it runs entirely in your browser, no Python web application server required. Read more about that in the Datasette Lite documentation.