# sqliteviz: a browser tab that runs SQL over a SQLite file you never upload

> A single page PWA where the database, the CSV parser and the charting library all run client side, so an investigative dataset can be opened without a server seeing it.

**lana-k/sqliteviz** — Instant offline SQL-powered data visualisation in your browser

- Repository: https://github.com/lana-k/sqliteviz
- Website: https://sqliteviz.com
- Stars: 2,356 · Forks: 135
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/lana-k-sqliteviz

## Everything runs in the tab, which is the whole premise

The README opens with a precise description: a single-page offline-first PWA for fully client-side visualization of SQLite databases, CSV, JSON or NDJSON files. Each phrase carries weight.

Single-page means there is no backend and no API. Offline-first means after the first load it works without a network, which matters because it implies the app is served from a cache and installs as a local application. Fully client-side is the load-bearing claim, because it means your data never leaves the browser. That is the feature that distinguishes this from every hosted analytics tool, and it is why the file formats are local ones.

The last of those phrases is worth pausing on. You can open a SQLite database, a CSV, a JSON file, or NDJSON, which is newline-delimited JSON for large record streams. Four input formats is a real widening of the use case, and the pivot and graph features make sense once you consider that the intended datasets are investigative, the kind where you have a dump and you are looking for structure rather than monitoring a production system.

The practical consequence is that you can take a file of questionable provenance, open it, and query it, without an upload dialog anywhere. For a tool that will meet with real datasets, that is not a nicety.

The release cadence supports the reading. Three releases in 2026: 0.30.0 in April, 0.30.1 in July, and 0.31.0 in late July. The last push was 2026-07-26, and the repository is not archived.

## What you can do once the data is loaded

The README lists the capabilities as a bulleted list, and it is more varied than a single-feature chart tool would be.

You can run SQL queries against a SQLite database and create Plotly charts, graphs and pivot tables from the result sets. You can import a CSV, JSON or NDJSON file into a SQLite database and visualize the imported data, which means the file formats other than SQLite are normalized into SQLite before you query them. You can export a result set to a CSV file. You can manage inquiries and run them against different databases, which is the saved-query feature. You can import and export inquiries to and from a JSON file. And you can export a modified SQLite database, which is the one that surprises people: if your import or query changed something, you can write the database back out.

The inquiry feature is the piece with the most leverage if you work with the same question repeatedly. A saved query that you can re-run against a different database turns a one-off exploration into a repeatable process, and being able to export and import those inquiries as JSON means the collection is portable and reviewable.

The stated motivation is a positioning rather than a technical claim: it is a kind of middleground between Plotly Falcon and Redash. That comparison is the honest framing for the whole project. Redash is a server-side analytics tool with users, permissions and a database of dashboards. Falcon is a client-side charting library. sqliteviz is deliberately neither, and the feature list is the argument for that middle position.

## A dependency list that explains the architecture

The README has a Components section naming the libraries, and reading it tells you how the app is assembled rather than just what it can do.

The core is built on top of react-chart-editor, PivotTable.js, sql.js and Vue-Codemirror in Vue.js. CSV parsing is done by Papa Parse. Graph visualization is handled by Sigma.js with Graphology. The link references identify each: sql.js is the SQLite compiled to WebAssembly, PivotTable.js is the pivot table implementation, Sigma.js is the graph renderer, and Graphology is the graph data structure library.

The `package.json` confirms and extends that. `sql.js` is not pulled from a registry but referenced as `file:./lib/sql-js`, which means the project vendors its own copy of the SQLite WebAssembly build rather than depending on the published package. That is a deliberate choice, and it explains the presence of a `patches/` directory alongside a `postinstall` script that runs `patch-package`. When a dependency needs a local modification after install, the patch is applied automatically, which keeps the change reviewable in the repository rather than hidden in someone's build environment.

The rest of the dependency list is broad, which is consistent with an application rather than a library. It includes `plotly.js` at a 2.x version, `pivottable`, `sigma`, `graphology` and `graphology-layout-forceatlas2`. It also includes `html2canvas` for image export, `seedrandom` for reproducible force layouts, `nanoid`, and `tiny-emitter` for event handling.

Two entries stand out for what they imply. `promise-worker` is a Web Worker wrapper, which is how the SQLite work is moved off the main thread so the UI does not freeze during a large query. And the package is `private: true`, so it is an application repository, not something published to npm.

## Releases that show where the effort actually goes

The three recent releases are small and each one names a single change or pair of changes. Reading them together gives a clearer picture of the project's direction than the feature list does.

Version 0.31.0, on 2026-07-26, added view details of points selected in a Plotly chart. That is a small analytical affordance, the ability to click a mark and see what row produced it, and it is the kind of feature that only makes sense once the chart and the result set are in the same view.

Version 0.30.1, on 2026-07-12, fixed two bugs, and both are about configuration persistence rather than rendering. It made it possible to configure a custom chart in pivot visualization, where before it was not. And it stopped chart settings from being saved together with the data, which is a data separation bug: settings and result data were being persisted as one thing, so they could not be managed independently.

Version 0.30.0, on 2026-04-15, added support for configurable seed layouts for ForceAtlas2. ForceAtlas2 is the force-directed layout algorithm used by Graphology for placing graph nodes, and a seed layout makes the layout reproducible. Randomness in a layout algorithm means a graph looks slightly different every time you open it, which is bad when you are trying to compare two versions of the same graph.

So the recent work is concentrated on the analytical layer: point selection in charts, chart configuration in pivots, and reproducible graph layout. The SQL and import paths have not needed changes recently, which is either because they are stable or because they are not where the users are. Given that this is an exploratory tool, the second explanation seems more likely.

## Build tooling, and the two config files that hint at history

The root of the repository carries an unusual pair of build configuration files: `vite.config.js` and `vue.config.js`, together with `babel.config.js`.

A project does not normally have two bundler configs unless one is a leftover. Vite is the current build tool, driven by the `dev`, `build` and `serve` scripts in the `package.json`, which map to `vite`, `vite build` and `vite preview`. Vue CLI would have used `vue.config.js` and `babel.config.js`. The presence of all three suggests the project migrated from Vue CLI to Vite and did not remove the old files, which is common and harmless but does mean there are two possible answers to the question of how the app is built, and only one of them is current.

Testing runs through Karma rather than a modern runner. The `test` script is `karma start karma.conf.cjs`, with `karma.conf.cjs` and `test.setup.js` at the root and a `tests/` directory. Karma is a browser-based runner, which is a reasonable choice for a project whose entire value proposition is that it works in a browser, since it tests in the environment that matters.

There is a `.browserslistrc`, which is meaningful for an offline-first PWA, because it declares which browsers you intend to support and therefore which transforms get applied. And there is a `Dockerfile.test`, so there is a containerized test path for the CI, alongside a `.github/` directory holding the workflows.

There is also an `index.html` at the root and a `public/` directory, which is the standard Vite layout for static assets.

## Where it fits, and what to check before trusting it with a large file

The honest comparison is the one the project makes. Against a chart library like Falcon, sqliteviz adds a database, an import path and saved queries. Against a server-side tool like Redash, it removes the server, the sharing, the permissions and the scheduled refreshes, and gains the guarantee that your data never leaves the machine.

That trade is good for one specific workflow and bad for another. If you need to share a dashboard with colleagues, or refresh it on a schedule, or apply row-level permissions, this is the wrong tool, because there is no server to hold any of that. If you have a CSV you are not allowed to upload and a question about it, it is exactly right.

The performance question is the one to check yourself. Everything runs in a browser, which means the SQLite engine is running under WebAssembly and the charting is happening in a tab. That is comfortable for files in the tens of megabytes and less comfortable above that. The pivot table and the graph view are the two features most likely to struggle, and they are also the two that arrived most recently.

The wiki holds the user documentation and there is a separate docs site linked from the README. The motivation section's framing is the best single sentence to evaluate the project against: a middleground between Plotly Falcon and Redash, for people who want the query interface of the latter without the server of the latter.

## Conclusion

sqliteviz occupies a deliberate gap between two things it names itself against. It is too heavy to be a chart library and too focused to be a business intelligence tool, and the gap it fills is the one where you have a data file and a question about it, and uploading that file to somebody's server is not acceptable. Everything runs client side: sql.js compiles SQLite to WebAssembly, Papa Parse handles CSV, Plotly renders charts, and the whole app is installable and works offline from your OS application menu. The release history shows steady work on the pivot and graph features rather than on the SQL core, which suggests the analytical layer is where the effort goes. If you want to start, load the hosted app, import a CSV, and write the query in the editor. Before you rely on it for large files, check the pivot and graph performance yourself, since those two features arrived most recently and have had the least time to accumulate bug fixes.

## FAQ

### What are the downsides of using SQLite?

For sqliteviz specifically, the constraint is that the whole engine runs in the browser under WebAssembly, so very large files are slower than the same query against a server-side SQLite. Everything else about SQLite, including SQL compatibility, is a benefit here, since it means you can write ordinary SQL against an imported CSV. Feature requests on the repository have focused on chart selection and pivot configuration rather than on SQL limitations.

### Is SQLite obsolete?

That question is about SQLite the embedded database rather than this tool. sqliteviz is built on SQLite compiled to WebAssembly via sql.js, and the project's own direction has been to lean harder on the surrounding analytical features, adding chart point selection, configurable pivot charts and reproducible graph layouts in 2026. The database format is the stable part here and it is not the part receiving new work.

### Does sqliteviz send my data to a server?

No. The README describes it as a single-page offline-first PWA with fully client-side visualization, and it works with SQLite databases, CSV, JSON and NDJSON files opened locally. Because sql.js runs SQLite as WebAssembly in the tab, the file is read in your browser, and the app is installable and works offline from your OS application menu.

### Can I query a CSV file with sqliteviz?

Yes. The app imports CSV, JSON and NDJSON into a SQLite database and then lets you query it with SQL, using Papa Parse for the CSV parsing. You can also export result sets back to CSV, and export a modified SQLite database if your work changed the data.

### What can sqliteviz do with query results?

You can build Plotly charts, pivot tables and graph visualizations from result sets. Release 0.31.0 added viewing details for points selected in a chart, 0.30.1 made custom charts configurable in pivot views and stopped chart settings from being saved with the data, and 0.30.0 added configurable seed layouts so ForceAtlas2 graph layouts are reproducible.

## Sources

- [lana-k/sqliteviz on GitHub](https://github.com/lana-k/sqliteviz)
- [License: Apache-2.0](https://github.com/lana-k/sqliteviz/blob/master/LICENSE)
- [Project website](https://sqliteviz.com)
- [README](https://github.com/lana-k/sqliteviz/blob/master/README.md)
- [Releases](https://github.com/lana-k/sqliteviz/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lana-k-sqliteviz