Datasette: publish SQLite as an explorable site and API

The problem Datasette solves for data publishers

Most people who want to publish a dataset do not want to build a web application. They want a table they can sort, filter, page through, and hand to a colleague as a URL. The README describes Datasette as a tool that helps people "take data of any shape or size and publish that as an interactive, explorable website and accompanying API", and it names the audience directly: data journalists, museum curators, archivists, local governments, scientists and researchers.

The design decision that follows from that audience is the storage format. Datasette is built around SQLite files. That means the unit of publishing is a single file you can copy, email, put on a USB stick, or commit to a repository. There is no separate database server to keep running, no connection string to configure, and no migration step between the file you have and the site you want. If your data is already a CSV, the ecosystem around Datasette is built for converting it, and the project's own sqlite-utils dependency is listed in pyproject.toml.

This is not a general-purpose application framework. Datasette is closer to a viewer with an API attached. The practical consequence is that it is very good at the read path and mostly silent about the write path.

How Datasette serves a database: ASGI, Jinja2 and generated JSON

The dependency list in pyproject.toml tells you most of the architecture. Datasette is an ASGI application: it depends on asgiref, uvicorn, and httpx2, and the Python entry point is registered as datasette.cli:cli through [project.scripts]. Rendering goes through Jinja2 templates, configuration through PyYAML and mergedeep, and plugin wiring through pluggy. The front end is not a single-page app; package.json shows CodeMirror 6 and a rollup build used for the SQL editor assets, with prettier as the only dev tool.

Every page has a parallel JSON representation. The README notes that license and source metadata supplied via metadata.json "will also be included in the JSON produced by the API". That is the core data flow: one SQLite file goes in, and both an HTML view and a machine-readable response come out of the same routes. You do not enable the API as a separate feature.

Plugins are the extension mechanism, and they hook into the same request path rather than running as a sidecar. The pyproject.toml also registers datasette._pytest_plugin under pytest11, so plugins can be tested against Datasette's own fixtures. The project is classified as "Development Status :: 4 - Beta", which is worth reading literally: the 1.0 series is still shipping alphas, and the most recent release listed is 1.0a40 alongside a 0.65.5 maintenance release.

Installing Datasette and serving your first SQLite file

The README gives three installation routes. On a Mac, Homebrew is described as the easiest. Otherwise pip or pipx. Datasette requires Python 3.10 or higher, a constraint also recorded in pyproject.toml as requires-python = ">=3.10".

pip install datasette

After that, point it at a database file. The README's basic usage example is a single command, and serve is the default subcommand, so it can be omitted.

datasette serve path/to/database.db

The documentation states this starts a web server on port 8001, so you visit http://localhost:8001/ to reach the web interface. If you want to try it without creating a database first, the README shows a Chrome example on macOS that opens the browser history database directly, with the --nolock flag to avoid locking the file, and then browsing http://localhost:8001/History/downloads.

To add licensing and attribution, write a metadata.json and pass it with -m. The README's example looks 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"
}

Run datasette serve fivethirtyeight.db -m metadata.json and the README says the license and source appear on the index page, in the footer, and in the API's JSON output. There is also a Dockerfile in the repository root that takes a VERSION build argument, exposes port 8001, and defaults to the datasette command, for teams that would rather not install Python locally.

Publishing without a server, and the Datasette Lite shortcut

The README documents a publish subcommand that targets Heroku or Google Cloud Run. With either configured, datasette publish heroku database.db or datasette publish cloudrun database.db builds a Docker image containing both the application and the SQLite files, deploys it, and returns a URL. That is a real reduction in work compared with writing a Dockerfile and a deploy pipeline, but it does tie the command to those two platforms. The README does not document a generic target, and it does not document rollback of a published deployment, so treat the publish command as a one-way convenience rather than a release process.

Datasette Lite is the other end of the spectrum. It is Datasette packaged with WebAssembly so it runs entirely in the browser with no Python server, and the README links to a separate repository for it. For a dataset small enough to load in a tab, that removes hosting entirely. The trade-off is that anything requiring a server-side plugin, authentication, or a large database is out of scope there.

If you want to see the current main branch before installing anything, the project publishes a live demo at latest.datasette.io, and there is a GitHub Codespaces route through datasette-studio.

Where Datasette is the wrong tool

The first limitation is the storage engine. Datasette reads SQLite. If your data lives in Postgres or MySQL and must stay there, Datasette is not a drop-in front end; the RELATED SEARCHES terms around Postgres and DuckDB point at questions the README itself does not answer, and no Postgres or DuckDB backend appears in the dependency list. You would be looking at exporting to SQLite or at a different tool.

The second is write access. Datasette is presented as a tool for exploring and publishing data, not for editing it. If your users need to update rows through a form, you are building that yourself through plugins, and the built-in permission model is the starting point rather than a finished authorization system.

The third is the release line. pyproject.toml classifies the package as Beta, and the release list mixes 1.0 alphas with a 0.65 maintenance release. Pinning to a 1.0a version means tracking a moving target; pinning to 0.65 means you are not on the path the project is developing. Neither is wrong, but you should decide deliberately rather than letting pip pick.

Finally, SQLite's concurrency model is a real constraint for high-write workloads. Datasette's read-only posture sidesteps most of it, and that is arguably the point, but it also means Datasette is not the layer you put in front of a busy transactional database.

Datasette compared with a general web framework

The obvious alternative is Django or FastAPI plus a template layer. The difference is not speed or language, it is where the work sits. With a framework you define models, routes, serializers, pagination, filtering, and an admin interface, then wire them to a database. Datasette starts from the database file and generates the table views, faceted filtering, pagination, and JSON endpoints from the schema itself. You get less control and far less code.

The cost of that trade is customization. A framework lets you express arbitrary business logic in a request. Datasette wants that logic to arrive as a plugin, and plugins are written against Datasette's own hook system rather than as ordinary routes. For a team that already has a Django application, adding Datasette as a read-only data browser alongside it is usually cheaper than rebuilding the browse experience inside the app. For a team whose product is the application, Datasette is an extra deployment to maintain.

There is also the static-site option: generate HTML from the data at build time. That wins on hosting cost and loses on interactivity, since faceting and ad-hoc SQL need a running process.

Maintenance, licensing and the upgrade path

The last push to the repository was on 2026-09-21, and the most recent releases listed are 1.0a40 and 0.65.5, both dated 2026-09-16. That is a project shipping on two tracks at once: a 1.0 alpha series and a 0.65 line. The practical implication is that upgrading is a decision, not a routine. If you depend on plugins, check them against whichever track you pick, because a plugin written for 0.65 may not be ready for the 1.0 alphas.

Datasette is licensed Apache-2.0, recorded both in the README badge and as license = "Apache-2.0" in pyproject.toml. That is a permissive licence with an explicit patent grant, and it does not impose copyleft obligations on your own code. It says nothing about the licence of the data you publish, which is a separate question and the reason metadata.json exists: the README's example carries license, license_url, source and source_url so attribution travels with the site and the API responses. This is not legal advice; if you are publishing third-party data, the licence fields are a place to record your answer, not a substitute for one.

The upgrade cost is mostly Python and plugin compatibility. Datasette requires Python 3.10 or higher, and the Dockerfile builds on python:3.11-slim-bookworm, so container users are pinned to that base image unless they build their own. The repository has a Justfile and a pytest.ini, which suggests the project's own test workflow is scripted, but that does not tell you anything about your plugins.

Editorial conclusion

Adopt Datasette if you already have SQLite files, or can produce them, and you want a browsable site plus JSON API without writing an application. Skip it if your data lives in Postgres and must stay there, or if you need per-row write access and a full auth model out of the box. Before committing, check the 1.0a series against the stable 0.65 line, confirm your Python is 3.10 or higher, and decide whether the built-in permissions are enough or you need plugins for authentication.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. simonw/datasette on GitHub