For my workflow I’ve always looked for performance, especially since some time ago I had a really outdated machine and any kind of bloat was really noticeable, I remember using DBeaver and it just crashing on me multiple times, I also had to use postGIS which just made it worse. I migrated all my essential dev tools to use the ones with performance in mind (Zed, Ghostty etc) but the only thing that was missing was DB Client. The main choices everyone has are DBeaver which is a memory hog and an overkill for most of the tasks imo. The other options like Datagrid, Beekeeper, TablePlus are either electron based so bloated and memory hogs or paid and closed-source.
DBDelve 0.3.6 against DBeaver 25.3.1 on the same Postgres table, median of 5 runs each (2026-10-11, M1 Pro, 32 GB). Times are from the action to the rows rendered.
DBDelve DBeaver
Launch 1.1 s 5.2 s
Idle memory 133 MB 606 MB
1,000-row query 0.21 s 1.96 s
1M rows, time 56 s 208 s
1M rows, memory [1] 4.9 GB 17 GB
[1] The whole 1M-row, 100-column table pulled into memory on purpose, with the row limit off. Not a normal use case; DBeaver's heap limit had to be raised manually for the benchmark.Scrolling perf with 1 million rows loaded with 100 columns each: https://youtu.be/V2MOhJYFqIE
It has most of the features most devs would need for 90% of their workflow plus some more I thought would be a nice touch: Readonly, read-write and Full Access modes Glass themes (If you’re into them, I am) Keyboard focused with every keybinding customizable Organization of connections into projects
Me and some other folks have been daily driving it for more than a month now and most good feedback comes on it having a really simple UI to navigate, very stable for its age and the performance of course. I’m also sharing here because those people tell me this has potential to grow so I’m trying my hand at distributing it.
Just want to give a huge shoutout here to the Zed team for GPUI, it's a breeze to work with if you just get through them not updating the crate officially on crates.io but the community has found the solutions for it, you just have to dig deep for it. It performs extremely well and just the HTML-like structure of it, makes it easy to understand for someone from a web dev background and agents are very good at writing it too. GPUI component also solves a lot of problems with having a good component library we can use. I think for anyone starting a GPUI project now, GPUI-kit makes a lot of sense, it just bundles GPUI, GPUI-component together and has some optimizations adding retained mode which is experimental but could provide a lot of benefit, so think all things considered it should be the default way.
The major optimization I did was just lowering the memory overhead by using packed rows which reduced the memory usage by 40% on large datasets (8.1GB to 4.9GB on a 4GB table loaded in app), everything else came bundled in with Rust and GPUI mostly or they just made it very easy.
Limitations: It's not signed and notarized, identity verification from apple's side has been a nightmare but it should be signed soon. Don’t expect feature parity with more mature clients for now, the general direction of this right now is the zed way of adding features in but after making sure the core workflows are done with a high quality.
Do give it a try, you can import your connections from dbeaver and tableplus.
what does this mean?
the ui does look very nice
(Workbench is a pain but it was capable, off-the-shelf and was possible to document it once, more or less, for multiple platforms; I did not actually hate using it. But alas it is old now)
I will surely test this out; good luck with it.