Show HN: Duck-UI – Browser-Based SQL IDE for DuckDB
demo.duckui.com(You can use it offline)
MotherDuck decided to take their web app UI and make it a locally usable extension via DuckDB. however as noted in that thread, the architecture is a bit odd as the actual page loads once the extension is running from MotherDuck’s servers (hence the online requirement)
I don’t think it’s intentionally malicious or bad design or anything, just how this extension came about (and sounds like they’re fixing it)
disclaimer: I do know and actively work with the MotherDuck folks, I’ve also worked w/ DuckDB Labs in the past
Separate entities, but cooperative/comprised of many overlapping people, right?
1. DuckLake is the best datalake spec and their team is improving on the extension rapidly.
2. With DuckDB WASM, you can make apps that would normally have 2 to 3 second latency for network calls work in < 200ms.
We use it as our built-in datalake at Definite and couldn't be happier with it.
INSTALL iceberg;
to start working with iceberg https://duckdb.org/docs/stable/core_extensions/iceberg/overv...
I was using it even before it hit 1.0
Something like a dashboard app for instance, might have callbacks where it needs to run a new SQL query based on input, but be small enough to make loading all data onto menory and querying locally a mich faster option.
Obviously ymmv and if you have a dashboard with a heavy data set under the hood, your gonna make a lot of users unhappy fast by doing that.
https://adsharma.github.io/graph-archiving/ https://adsharma.github.io/beating-the-CAP-theorem-for-graph...
The catalog is based on the now archived kuzu graph db project. Development continuing here: https://github.com/LadybugDB/ladybug
quote - google ai mode:
"DuckDB offers robust capabilities for querying data stored partially on S3, particularly when dealing with Parquet files. This is achieved through several optimization techniques:
Predicate Pushdown: When you apply a WHERE clause to filter data, DuckDB can "push down" this filter directly into the Parquet file scan. If the Parquet file contains zonemaps (metadata about value ranges within columns), DuckDB can use this information to skip reading entire sections of the file that do not contain relevant data, significantly reducing the amount of data transferred from S3.
Projection Pushdown: When you select only specific columns in your SELECT statement, DuckDB automatically reads only those required columns from the Parquet file. This means you avoid downloading and processing unnecessary data, leading to faster queries and reduced S3 transfer costs.
HTTP Range Reads: DuckDB leverages HTTP range headers when interacting with S3 (or other object storage supporting range reads). This allows it to fetch only the necessary parts of the Parquet file, such as metadata or specific column chunks, rather than downloading the entire file."
DuckDB is the single-most impressive piece of software I’ve used in my career. I’m mangling terabytes of parquets daily and it just handles them effortlessly; the bindings also also well-written.
[0] https://duckdb.org/docs/stable/clients/wasm/data_ingestion#a... [1] https://github.com/finos/perspective
Wonder if this work could be ported as a replacement to duckdb local UI?
Rill Data - https://www.rilldata.com Summer - https://summer.io Hex - https://hex.tech Evidence - https://evidence.dev
1. One of my favorite features from the built in DuckDB UI is the panel that automatically generates graphs for each column, both for the whole dataset itself and for the specific query you're running. I often find myself not even writing any queries because all I needed was something really simple already available in that panel. This would be my #1 reason for not using this GUI instead of the built in one.
2. I could not find any panel to show the currently selected value in the grid view. Ideally I would like this to also be able to auto-detect common formats like JSON and format them, etc.
3. The grid view can show a maximum of 200 rows. Finding a way to virtually render the rows in an infinite list would be much better IMO. I've found myself selecting up to 10k+ rows in the built in GUI and to copy all IDs, etc, several times (saves sometime compared to exporting a CSV and copying from there).
4. The column filter dropdown in the grid view has a search bar which is nice, but it is automatically deselected on each character entry, making it very annoying to use...
5. Additionally the dropdown filter menus are not automatically closed when you click outside or open another dropdown, which is a minor annoyance.
6. The right click menu in the grid viewer will close on "mouse out", however it does not close on "click outside" and the cursor does not start inside of the menu itself. This means the menu becomes permanently stuck until hover over it if you immediately move the mouse to the top-right on open.
7. The grid view resizer is behaving buggy sometimes after changing the number of page rows to display.
8. The transparent tooltip background in the chart viewer makes the light-gray text impossible to read in dark-mode when there is yellow behind it (from other the chart bars).
9. The explorer side panel seems to be sized based on a percentage of the window size. this is quite minor but it would behave nicer if it had a fixed size so changing the window size does not also resize the side panel. It is also overly large when you first load the site.
I ask because I am under the impression that the 'DuckDB Wasm' client provided by DuckDB doesn't yet support all of the DuckDB functions.
So I am interested to know if this has implemented more, fewer, or the same set of functions.
Using my textplot extension doesn't result in my expected output:
---
install textplot from community;
load textplot;
select tp_bar(0.5)
---