Dataset Viewer: A Tauri Desktop App for Streaming 100GB+ Files Over WebDAV, S3 and SSH
A sleek dataset viewer built entirely by AI Agent. Supports streaming large files from WebDAV, S3, SSH, Local or Hugging Face.
At a glance
- What is it?
- Dataset Viewer is an AI-generated Tauri and React desktop application that opens remote and local datasets without downloading them whole. It is a reasonable fit for log and Parquet browsing, and a poor fit for anyone who needs a stable plugin contract or a clear licence position.
- Who is it for?
- Adopt Dataset Viewer if you regularly open multi-gigabyte CSV, Parquet, JSON or log files that already live on an S3 bucket, WebDAV share or SSH host, and you want a desktop binary rather than a Jupyter cell. Do not adopt it if you need a guaranteed licence for commercial redistribution, a frozen plugin API, or a tool that has been regression-tested against your own storage backend.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 172 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: datasets that are too big to open and too remote to copy
The failure mode this project targets is mundane and common. A CSV or Parquet file sits on an S3 bucket or an SSH host, it is larger than the RAM of the laptop you are working on, and the only way to look at it is to download it, or to spin up a notebook and write a reader. Downloading a hundred gigabytes to check one column is a waste of time and bandwidth. Dataset Viewer's answer is a Tauri desktop application that connects to the source and streams the file in chunks instead. The README describes the target as files of 100GB and above, handled through virtualized rendering and chunked transmission, with the archive feature browsing ZIP and TAR contents without extraction. The intended audience named in the README is data scientists exploring Parquet and CSV, people searching large log files, and anyone who needs to browse compressed archives or reach storage over WebDAV, SSH/SFTP, SMB, S3 or Hugging Face Hub. That is a coherent niche: read-only inspection of data that stays where it is.
How the streaming and virtualized rendering fit together
The architecture visible in the README is a Tauri shell hosting a React front end. Tauri means the file and network work happens in a Rust backend rather than in the browser sandbox, which is what makes SSH/SFTP and SMB/CIFS connections possible at all; a pure web app cannot open those sockets. On top of that sit two mechanisms the README names explicitly: chunked loading with virtual scrolling, and chunked transmission for large files. Virtual scrolling is what lets a table claim millions of rows without rendering them, because only the visible window is drawn. Chunked loading is what keeps memory bounded, because the viewer reads a slice of the file rather than the whole object. The same idea is applied to archives: the README states that ZIP and TAR files can be previewed without extraction, which implies the reader resolves the archive index and pulls only the entries being viewed. Search is described as millisecond search with highlighting across massive files, and the README does not explain how the index is built or whether it is built at all, so treat that claim as unverified until you test it against your own data.
Supported formats and the plugin SDK
The format list is broad and split across categories. Text and code files include JSON, YAML, XML and a range of languages with syntax highlighting. Documents cover Markdown preview, Word .docx and .rtf, PowerPoint .pptx and searchable PDF. Data files are Parquet, Excel, CSV and ODS with virtual scrolling. Archives are ZIP and TAR. Media covers images, video and audio. There is also a point cloud viewer shown in the screenshots, which is unusual enough to be worth noting: it suggests the plugin system is already being used for domain-specific renderers rather than only for text formats. That plugin system is the part of the project with the most concrete external surface. The README points to a Plugin Development Guide in the repository wiki, an npm package published as @dataset-viewer/sdk, and example plugins under the packages directory, naming a CAD viewer and a sketch viewer. If you extend this tool, that SDK and those examples are the contract you are coding against, and the wiki is where the interface is documented.
Getting it running: download the release, then connect a storage backend
Installation follows the normal desktop pattern for a Tauri app. The README links to the latest release page at github.com/stardustai/dataset-viewer/releases/latest, and a platform badge advertises Windows, macOS and Linux. There is no documented package-manager install, no Homebrew formula, no winget identifier and no apt repository mentioned, so the release asset is the path. Once the app is open, the workflow starts at the connection screen shown in the screenshots, where you choose a storage type and supply its parameters. The README names the supported types as WebDAV, SSH/SFTP, SMB/CIFS, S3, Local Files and Hugging Face Hub, but it does not print the individual field names for each connection form, so I cannot give you exact config keys for, say, an S3 endpoint or an SSH key path. What the material does establish is the shape: one connection record per backend, then file browsing and viewing through that connection. For plugin work the command surface is npm, with the SDK published as @dataset-viewer/sdk and examples living under packages/ in the repository.
Where it breaks down: search cost, plugin churn and an unclear licence
Three limitations are visible from the material alone. The first is search. The README promises millisecond search across massive files but says nothing about how the index is produced. If the index is built lazily on first search, the first query on a 100GB remote file will not be instant, and if it is built eagerly, you are paying to read a file you may only glance at. That distinction matters more than the headline number, and the README does not resolve it. The second is the plugin API. The project shipped v1.6.2, v1.6.3 and v1.6.4 within roughly two days in October 2025, and the last push to the default branch is dated March 2026. A fast patch cadence on a young SDK means plugin authors should expect interface movement; the wiki guide is the only stability signal offered. The third is licensing, and it is the sharpest problem. The README carries an MIT badge, while the repository metadata supplied for this review lists the licence as unknown. Those two facts conflict, and nothing in the material resolves them. If you plan to redistribute the binary or embed the SDK in a commercial product, read the LICENSE file in the repository yourself rather than trusting the badge. This is not legal advice; it is a statement that the source of truth is missing from what I can see.
How it differs from DuckDB and the Parquet tooling you already have
The obvious alternative for large tabular files is DuckDB, usually driven from a CLI or a notebook. The difference is where the work happens. DuckDB is a query engine: you point it at a Parquet file, local or over httpfs and S3, and you get SQL results back. Dataset Viewer is a browser: it opens the file, renders rows, highlights matches and lets you scroll. If your question is what is the average of this column grouped by that one, DuckDB answers it and Dataset Viewer does not, because the README describes no query language and no aggregation. If your question is what does row four million look like, or what is inside this TAR, DuckDB gives you a SQL round trip and Dataset Viewer gives you a scroll. The other difference is deployment. DuckDB is a library you install into an existing Python or Node environment; Dataset Viewer is a standalone desktop binary aimed at people who do not want to write code to inspect a file. Neither replaces the other, and the README's own framing, data scientists and log analysis, is honest about which side of that line it sits on.
Maintenance cost and what the release history implies
The release record shows three patch releases in about two days in October 2025, then a gap, with the most recent push to main dated March 2026. That pattern is consistent with bursts of activity rather than a steady maintenance rhythm, and it has consequences for anyone building on the plugin SDK. A plugin written against @dataset-viewer/sdk at v1.6.4 may need rework if the SDK interface shifts; the wiki guide is the only documented contract, and there is no stated deprecation policy. The upgrade cost for the application itself is low, since it is a desktop binary you replace rather than a service you migrate. The upgrade cost for plugins is unknown and depends on how the SDK evolves. On licensing, the conflict between the MIT badge and the empty metadata field is the item to resolve before anything else, because it determines whether redistribution is even a question you are allowed to ask.
Who should install it, and what to check first
Dataset Viewer is worth installing if your daily work involves opening large CSV, Parquet, JSON or log files that live on remote storage and you want a desktop tool rather than a script. The multi-protocol connection layer is the part that is hardest to replace with a weekend script, particularly SSH/SFTP and SMB, and the archive preview without extraction is a genuinely useful trick when you are hunting through a directory of ZIP files. Skip it if you need SQL, if you need a plugin API with a stability guarantee, or if you need a licence position you can rely on today. Before committing, do two things. Open the LICENSE file in the repository and confirm what it actually says, because the README badge and the repository metadata disagree. Then download the release asset for your platform from the releases page and open one of your own large files over the storage backend you actually use, because the README's performance claims about 100GB files and millisecond search are described in the documentation but I have not verified them and neither has anyone whose results I can cite.
Editorial conclusion
Adopt Dataset Viewer if you regularly open multi-gigabyte CSV, Parquet, JSON or log files that already live on an S3 bucket, WebDAV share or SSH host, and you want a desktop binary rather than a Jupyter cell. Do not adopt it if you need a guaranteed licence for commercial redistribution, a frozen plugin API, or a tool that has been regression-tested against your own storage backend. Before installing, verify two things: the actual licence text in the repository, because the README badge says MIT while the metadata field is empty, and whether your target release asset exists for your platform, since the README only asserts Windows, macOS and Linux in a badge. Those two checks take minutes and decide whether the rest of the evaluation is worth doing.
Community notes