Show HN: SQL workbench in the browser
sql-workbench.com
sql-workbench.com
It’s a dangerous business, creating side projects. Before you know it, you build streaming parsers :)
It supports the querying remote and local data (Parquet, CSV and JSON), data visualizations and the sharing of multiple queries via URL.
There‘s also a tutorial blog post at https://tobilg.com/using-duckdb-wasm-for-in-browser-data-eng... that explains common usage patterns.
Happy to answer any questions!
Its not bad. The map by GPS isn't as great as Kepler.gl, and for some reason, perspective doesn't work so well in corporate offices that may be using Remote Browser Instances... had some issues.
SELECT count(*) FROM 'https://data.quacking.cloud/nyc-taxi-data/yellow_tripdata_2023-01.parquet';
Shows the error:Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://data.quacking.cloud/nyc-taxi-data/yellow_tripdata_20.... (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.
I get the same issue in both firefox and brave
edit: actually accessing that file directly gets a Access Denied error for me
https://sql-workbench.com/#queries=v0,SELECT-count(*)-FROM-'...
Thanks!
GitHub supports CORS for raw data for example, that's why I put it in the sample queries.
Using meta queries to fill my system prompt with the entire schema of the db in a condensed format.
It was working quite well!
Would love to hear about your approach.
Question is more where to host this "on the cheap" because this is a free service, and I can't just spend hundreds of Dollars/month to keep it running... Do you have any recommendations?
In general I don't think this would eat too many resources, just throw it on a VPS using systemd.
Architecture: https://evidence.dev/blog/why-we-built-usql/
1. Query SQL databases, APIs, or local data (eg CSV)
2. Compile all the data sources into Parquet files
3. DuckDB-WASM in the browser that allows you to aggregate across sources
4. Users write code in DuckDB SQL and Markdown, enriched with viz components (built in Svelte)
Some things that we have learned in the process:
- It can be pretty performant up to about 20M rows of data in the parquet files,
- Above a certain level, for speed, it's helpful to sort your data in your parquet files to take advantage of DuckDB's predicate pushdown
- It's helpful to map DB types into a smaller set of Arrow types when you convert to Parquet - otherwise you have to consider a lot of different cases in the browser when you render in JS
- DuckDB-WASM still has some rough edges, though is improving fast
I love how fast your workbench runs, and how effortlessly it renders 60k rows in the browser
Some UX feedback, if you're open to it:
- It was initially unintiutive for me that I needed to highlight a whole SQL statement to get Ctrl-Enter to run it. Also a prompt that this was the correct shortcut would help!
- I dragged in a CSV file, and the name was too long to show up in your table explorer, so I couldn't tell what the table name had been called (it turned out I needed to `select * from table_name.csv` - the csv postfix was unexpected
- The CSV file had headers, but they were not auto detected - would be good to be able to configure this
What would be a more intuitive way from your POV?
I‘ll look into the horizontal scrolling/CSV header issues, thanks!
Check out what Postico does; it just highlights the current statement under the cursor by default and that's what gets run by default. Can't resist imposing this subtle SQL UX on everyone because it's my favorite (for like 10 years now).
I‘ll look into this as fallback method. I don’t like Monaco Editor‘s handling of selections and cursors, it’s quite complicated, but this should be possible to implement…
I think I would execute the SQL query that the cursor was within.
Ie anything until the next ;