Show HN: Time Travel with Your SQL

[modelorona]

Hi, my name is Anguel and I am one of the developers of WhoDB (https://github.com/clidey/whodb)

I am not a fan of the dbeaver, beekeeper, adminer, etc experience because they are bloated, ugly, and at best okay but not great.

Hence why I started working on WhoDB.

The approach:

- browser-based (chrome/firefox)

- no bloat

- jupyter notebook-like experience (Scratchpad)

- built-in AI co-pilot with ollama (local) or openai/anthropic

We just shipped query history and replay (time travel?) to the Scratchpad.

Would love for you to check it out and give some feedback aka roast us into oblivion:

docker run -p 8080:8080 clidey/whodb

Food for thought:

1. What's your biggest database pain point?

2. Any killer feature missing from current tools?

[dleeftink]

Cool product.

> No more wasting time crafting complex SQL queries

I always wondered about this sentiment; isn't the time spent crafting complex queries a good thing when trying to understand a problem domain? I.e. incrementally refining your mental model of the data model

[datadrivenangel]

Some complexity is accidental (how do I do this gnarly window function and get the 3rd highest value from the previous week this time last year except on the first week of the quarter), and some is essential (why is the data like this?).

People confuse the two, and rightfully dislike the former while dangerously resenting the latter.

[johnthescott]

amen. get the schema correct and the gui will follow.

[jedberg]

When talking about Time Travel in regards to a database, that term usually means "seeing what the data looked like at a specific time". From my brief skim here, I don't see that.

Is that concept built in somewhere?

[listenallyall]

> query history and replay

For clarification- am I correct that what you are referring to as "time travel" is simply a history list of prior queries you've run? Can I today, run a query and see what the results would have been in the database last month (or yesterday, or 2 hours ago, etc)?

[tarasyarema]

I also understood that, but seems unreasonable to be able to achieve it without somehow storing the state via scd or some sort of audit + multi engine support

[listenallyall]

Sure it's a complex, difficult feature. But that's what "time travel" typically means in terms of querying databases. It's the headline of this article, the fact that what they really mean is a simple query log, is kind of bait-and-switch.

[BoorishBears]

Unsolicited feedback (or I guess solicited reading the post again): Juypter Notebook experience got me to click because I thought this might be like a Deepnote alternative

But the only screenshot on the Github page was decidedly not that. It wasn't showing something very appealing visually, or immediately obvious in terms of necessity for a tool calling its competitors ugly and bloated

I don't use any of the ones you listed so maybe they're even uglier, but I would maybe tweak the pitch and make it clearer who this is for

[neximo64]

1. The tools are always web based and have a bloated and bad experience as opposed to a complete native app.

2. Charts, easy ability to find the database if there are so many

[Rucadi]

I don't see much difference between a native app and web app, in the end is what the developer decided to do with that.

See autocad for web for example, is kinda the same. Or Photopea, photoshop's clone.

[djfobbz]

Nice product! I'm also not a big fan of DBeaver, Beekeeper, or Adminer. However, I do use HeidiSQL, and it's been lightweight and robust for me over the last 20 years. One feature I really appreciate is the query history, which is categorized by date. Have you ever given it a try?

[getgalaxy]

getgalaxy.io ;)

[amadeuspagel]

You might want to make the sample db read only.

[xnx]

> I am not a fan of the dbeaver, beekeeper, adminer, etc experience because they are bloated, ugly, and at best okay but not great

What you call "bloated", I call "features". What you call "ugly", I call "functional".

[jf22]

I've never made a software usage decision because a product felt "too bloated" for us to use.

[rprtr258]

how did you manage to put

- no bloat

- built-in AI co-pilot with ollama (local) or openai/anthropic

into one list?

[Natfan]

Pretty easily, as it happens[0]. Just implement the RESTful methods as appropriate. Ollama supports the OpenAI API spec

[0]: https://github.com/clidey/whodb/blob/main/core/src/llm/llm_c...

[1]: https://github.com/openai/openai-openapi

[vivzkestrel]

"Conversate With Your Data: No more wasting time crafting complex SQL queries - ask away!"

Maybe it is just me but literally every single product that has tried to eliminate SQL somehow with a conversational interface has never seen mass success, if they did, we wouldn't be using SQL anymore