EasyDB: a desktop SQL editor that treats your files as tables

Files as tables, with a query engine inside the app

EasyDB is described as a lightweight desktop data query tool built with Rust and Tauri that ships with a built-in Apache DataFusion query engine, and the promise is that you need to install no database and no other dependencies, just use SQL to query local files directly. The framing that makes it useful is that it treats files as database tables. The supported sources are CSV, TSV, plain text, JSON, newline-delimited JSON, Excel, Parquet, MySQL and PostgreSQL, and on top of that it supports multi-table joins, subqueries, window functions and other advanced SQL features. The README claims it handles data files from hundreds of megabytes to several gigabytes with minimal hardware resources, and the core feature list attributes that to the Rust and DataFusion base and to low memory usage. It is a desktop application with a native window, and the platform badge lists macOS and Windows.

The reader functions are the API you actually learn

The file reader functions are listed individually in the roadmap, and reading them tells you the shape of the whole tool. There is read_csv with options for a custom delimiter, a header and schema inference, read_tsv, read_text with a custom delimiter, read_json which handles standard JSON arrays and auto-detects newline-delimited JSON, and read_ndjson for one JSON object per line. Then read_excel and read_xlsx with worksheet selection, read_parquet for columnar storage, and read_mysql and read_postgres for database tables. The scalar functions list currently holds one entry, REGEXP_LIKE for regular expression matching. Each reader takes a path or a connection plus named arguments, which is the DataFusion named-argument style, and that is what makes a query read like a small program rather than a plain SELECT over a registered table.

An engine swap from Polars back to DataFusion, for SQL coverage

The engine selection section is the most revealing part of the README, because it explains the project's own history. Version 1.0 previously used the Polars engine, which excelled in stream processing and memory usage but had limitations in complex SQL support, and version 2.0 switched back to DataFusion for more complete SQL support while maintaining good performance and resource efficiency. The stated reason for choosing DataFusion over Polars is that it offers more comprehensive SQL compatibility, and the README notes it is part of the Apache Arrow project. So the constraint on this tool is not raw speed but how much of the SQL language it will accept, and the answer is that a query which DataFusion can parse will run. That is also why the list of supported features is long: joins, subqueries, window functions, regex matching and the full set of reader functions all come from the engine rather than from the app.

The query syntax, and how a file becomes a table

The user guide shows the syntax, and the shape is a FROM clause naming a reader function with its arguments inline.

-- Query CSV files
SELECT *
FROM read_csv('/path/to/file.csv', infer_schema => false)
WHERE "age" > 30
LIMIT 10;

The other readers follow the same pattern, with a path or a table name and the named arguments that reader needs.

-- Query Excel files (specific worksheet)
SELECT *
FROM read_excel('/path/to/file.xlsx', sheet_name => 'Sheet2')
WHERE "age" > 30;

A database table works the same way, with a connection string or a set of host and credential arguments rather than a file path. Because the readers are just functions in the FROM clause, you can join a local file to a live database table in a single statement, which the README demonstrates with an Excel file inner joined to a MySQL users table. The named argument syntax, using the fat arrow, is DataFusion's, and the infer_schema option on the CSV reader is what lets you query a file whose columns would otherwise be guessed.

Editor features, export, and the data grid

The editor and interaction list covers what a SQL workbench needs. Drag and drop of a file generates the query for you, with an option to insert the full statement or just the reader function call. Autocomplete covers function names, parameter names and result column names. You can execute a selected fragment of the statement rather than the whole thing, and there is formatting and clearing. The core feature list adds syntax highlighting, a modern interface built with Tauri v2 and HeroUI, and internationalisation with Simplified Chinese and English, auto-detected from the browser language. For results, the grid uses virtual scrolling and pagination so that a large result set renders smoothly with scroll-to-load, and the query history keeps the last fifty queries with their execution status. The result export options are CSV, TSV or SQL, with the SQL export able to emit INSERT or UPDATE statements in either MySQL or PostgreSQL dialect, which is the useful case for moving a cleaned result set into a real database.

A Tauri, React and DataFusion stack with a Rust side

The technical architecture table lists the whole stack, and it is worth reading because it shows which problems the app solved with a library and which it solved itself. The frontend is React 18 with TypeScript and Vite, the backend is Rust with Tauri v2, the query engine is Apache DataFusion 50.3, and the UI framework is HeroUI with Tailwind CSS. Virtual scrolling and tables come from the tanstack react-virtual and react-table packages, the SQL editor is Ace through react-ace, and SQL parsing is done twice, with sqlparser-rs on the Rust side and node-sql-parser on the JavaScript side. Internationalisation is a lightweight custom implementation for zh-CN and en-US rather than a full framework, and the history storage is SQLite through rusqlite. The package manifest confirms the front end is a private package named easydb-frontend at version 2.12.1, with Tauri at 2.11.0, and the repository has a src-tauri directory for the Rust side, a scripts directory, a fixtures directory and separate English and Chinese changelogs, with a VERSION_MANAGEMENT.md describing the release process.

The planned list tells you what is not there yet

The roadmap is worth reading for what is still open. Excel lazy loading performance optimisation is not done, nor is enhanced data type compatibility for Excel, so a large workbook is the slowest path in the app right now. Multi-session window support is on the list, which means you run one session at a time today. Directory browsing is planned, so you pick files individually rather than pointing at a folder. S3 remote file support and direct querying of server files are both on the list, which means everything is local today. And data visualisation is listed as planned, so the app is a query tool and an export tool rather than a dashboard. The licence is MIT, the repository is not archived, and the last push was on 2026-08-14, with the recent release tags on v2.12.1, v2.12.0 and v2.11.0 from June 2026.

Editorial conclusion

EasyDB fits someone who has a folder of data exports and wants to ask questions of them with SQL rather than a spreadsheet, and who wants to join a local file against a live database table in one statement. It does not fit a team that needs scheduled or server-side reporting, since it is a desktop application, and it does not fit a Linux user, since the README lists macOS and Windows. Verify first which file readers cover the formats you have, since Excel reading is listed as needing performance work, and read the engine selection notes so you know which SQL features you can rely on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. shencangsheng/easydb_app on GitHub