When you have lots of rows, you want to think more in terms of set operations; and when you have complex data, you'll want to structure it relationally, and then you'll have a bunch of little tables filled with ids. In this case, something tree-like would be better to follow the indirections.

It's pretty rare - mostly for ad-hoc interactive debugging, typically where there's some UI missing or not yet implemented - that you'd want to edit a single row's contents.

actually, you were bang on the usecase ("typically where there's some UI missing or not yet implemented "), but not for debugging.

In fact, if I'm not wrong there was a startup that got launched on HN or PH or somewhere that just builds database connected spreadsheet-like webapps.

The thing is - in operations driven startups, the early days are built on top of spreadsheets. Which can get unmanageable within days. So then you start building your webapp. Something like dbeaver turns into a godsend because you then use the database as a spreadsheet, while you take your time building the webapp.

A spreadsheet is so much more common than a webapp with an opinionated UI - it was so surprising that when I handed over dbeaver to an operations guy, he actually had zero trouble using it to do his work. In fact the UI we are building now is on top of Handsontable (a JS spreadsheet component) rather than a form-like web component. Everyone is just so used to copy pasting rows, manipulating data,etc.

Because when you have a couple million rows in a table, you don't want to edit it à la Excel ;-)

not all kinds of editing are changing a billion rows at a time. Sometimes, you just want to change a few rows and few columns. I have actually used dbeaver as an order management system, while my front end caught up.

That's a really interesting use case, thanks for mentioning it.

Truth! Also, for its support of alternative databases like Mongo and Cassandra.