Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SnapQL – Desktop app to query Postgres with AI

github.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#61

Post by sgarland »

brulard wrote: post #59
sgarland wrote: post #55

Genuinely do not understand the point of these tools. There is already a practically natural language to query RDBMS; it’s called SQL. I guarantee you, anyone who knows any other language could learn enough SQL to do 99% of what they wanted in a couple of hours. Give it a day of intensive study, and you’d know the rest. It’s just not that complicated.

SQL is simple for simple needs, basic joins and some basic aggregates. Even that you won't learn in 2 hours. And that is just scratching the surface of what can be done in SQL and what you need to query. With LLMs and tools like this you simply say what you need in english, you don't need to understand the normalizations, m:n relation tables, CTEs, functions, JSON access operators, etc.

For reference, I’m a DBRE. IMO, yes, most people can learn basic joins and aggregates in a couple of hours, but that is subjective.

> you don’t need to understand the normalizations

You definitely should. Normalizing isn’t that difficult of a concept, Wikipedia has terrific descriptions of each level.

As to the rest, maybe read docs? This is my primary frustration with LLMs in general: people seem to believe that they’re just as good of developers as someone who has read the source documentation, because a robot told them the answer. If you don’t understand what you’re doing, you cannot possibly understand the implications and trade-offs.

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#63

Post by physix »

sgarland wrote: post #55

Genuinely do not understand the point of these tools. There is already a practically natural language to query RDBMS; it’s called SQL. I guarantee you, anyone who knows any other language could learn enough SQL to do 99% of what they wanted in a couple of hours. Give it a day of intensive study, and you’d know the rest. It’s just not that complicated.

Without having looked at it, I would assume the value comes from not having to know the data model in great detail, such that you can phrase your query using natural language, like

"Give me all the back office account postings for payment transfers of CCP cleared IRD trades which settled yesterday with a payment amount over 1M having a value date in two days"

That's what I'd like to be able to say and get an accurate response.

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#64

Post by sgarland »

brulard wrote: post #60
sgarland wrote: post #57

Earlier quoted context omitted.

Mostly because you don’t know if it’s correct unless you know SQL. It’s entirely too easy to get results that look correct but aren’t, especially when using windowing functions and the like. But honestly, most queries I’ve ever seen are just simple joins, which shouldn’t take you 5 minutes to write.

> most queries I’ve ever seen are just simple joins Good for you. Some of us deal with more complex queries, even if it may not seems so from the outside. For example getting hierarchical data based on parent_id, while having non-trivial conditions for the parents and the children or product search queries which need to use trigram functions with some ranking, depending on product availability across stores and user…

> getting hierarchical data based on parent_id

So, an adjacency list (probably, though there are many alternatives, which are usually better). That’s not complex, that’s a self-join.

> trigram functions

That’s an indexing decision, not a query. It’s also usually a waste: if you’re doing something like looking up a user by email or name, and you don’t want case sensitivity to wreck your plan, then use a case-insensitive collation for that column.

> I agree knowing SQL is still useful, but more for double checking the queries from LLMs

“I agree knowing Python / TypeScript / Golang is still useful, but more for double checking the queries from LLMs.” This sounds utterly absurd, because it is. Why SQL is seen as a nice-to-have instead of its reality - the beating heart of every company - is beyond me.

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#65

Post by sgarland »

AdieuToLogic wrote: post #58
sgarland wrote: post #57

Earlier quoted context omitted.

Mostly because you don’t know if it’s correct unless you know SQL. It’s entirely too easy to get results that look correct but aren’t, especially when using windowing functions and the like. But honestly, most queries I’ve ever seen are just simple joins, which shouldn’t take you 5 minutes to write.

> Mostly because you don’t know if it’s correct unless you know SQL. It’s entirely too easy to get results that look correct but aren’t ... This is the fundamental problem when attempting to use "GenAI" to make program code, SQL or otherwise. All one would have to do is substitute SQL with language/library of choice above and it would be just as applicable.

Fully agree, I just harp on SQL because a. It’s my niche b. It always seems to be a “you can know this, but it doesn’t really matter” thing even for people who regularly interact with RDBMS, and it drives me bonkers.

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#66

Post by v5v3 »

sgarland wrote: post #55

Genuinely do not understand the point of these tools. There is already a practically natural language to query RDBMS; it’s called SQL. I guarantee you, anyone who knows any other language could learn enough SQL to do 99% of what they wanted in a couple of hours. Give it a day of intensive study, and you’d know the rest. It’s just not that complicated.

In a business, a management decision maker has to rely on a Db analyst if any query they have cannot be answered by any front end tool they have been given. And that introduces latency to the process

A 100% accurate ai powered solution would have many customers.

But can this generation of llms produce 100% accuracy?

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#67

Post by brulard »

sgarland wrote: post #64
brulard wrote: post #60

Earlier quoted context omitted.

> most queries I’ve ever seen are just simple joins Good for you. Some of us deal with more complex queries, even if it may not seems so from the outside. For example getting hierarchical data based on parent_id, while having non-trivial conditions for the parents and the children or product search queries which need to use trigram functions with some ranking, depending on product availability across stores and user…

> getting hierarchical data based on parent_id So, an adjacency list (probably, though there are many alternatives, which are usually better). That’s not complex, that’s a self-join. > trigram functions That’s an indexing decision, not a query. It’s also usually a waste: if you’re doing something like looking up a user by email or name, and you don’t want case sensitivity to wreck your plan, then use a case-insensiti…

Your Python / TypeScript etc. argument is a strawman, thats why it sounds absurd. Your arguments would hold better if an average person was good and very quick at learning and memoizing complex new things. I don't know if you work with people like that, but that's definitely not the norm. Even developers know little SQL unless it's their specific focus.

In the original comment you said:

> I guarantee you, anyone who knows any other language could learn enough SQL to do 99% of what they wanted in a couple of hours. Give it a day of intensive study, and you’d know the rest. It’s just not that complicated.

Well your "guarantee" does not hold up. Where I live, every college level developer went through multiple semesters of database courses and yet I don't see these people proficient in SQL. In couple hours? 99% of what they need? Absurd

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#68

Post by aurareturn »

sgarland wrote: post #61
brulard wrote: post #59

Earlier quoted context omitted.

SQL is simple for simple needs, basic joins and some basic aggregates. Even that you won't learn in 2 hours. And that is just scratching the surface of what can be done in SQL and what you need to query. With LLMs and tools like this you simply say what you need in english, you don't need to understand the normalizations, m:n relation tables, CTEs, functions, JSON access operators, etc.

For reference, I’m a DBRE. IMO, yes, most people can learn basic joins and aggregates in a couple of hours, but that is subjective. > you don’t need to understand the normalizations You definitely should. Normalizing isn’t that difficult of a concept, Wikipedia has terrific descriptions of each level. As to the rest, maybe read docs? This is my primary frustration with LLMs in general: people seem to believe that the…

Thank goodness 99% don’t want to understand everything. Otherwise, you wouldn’t be paid very well at your job, right?

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#69

Post by joshstrange »

I might test this out, but I worry that it suffers from the same problems that I ran into the last time I played with LLMs writing queries. Specifically not understanding your schema. It might understand relations but most production tables have oddly named columns, potentially columns that changed function overtime, potentially deprecated columns, internal-lingo columns, and the list goes on.

Granted, I was using 3.5 at the time, but even with heavy prompting and trying to explain what certain tables/columns are used for, feeding it the schema, and feeding it sample rows, more often than not it produced garbage. Maybe 4o/o3/Claude4/etc can do better now, but I’m still skeptical.

Re: Show HN: SnapQL – Desktop app to query Postgres with AI

#70

Post by nicktikhonov »

joshstrange wrote: post #69

I might test this out, but I worry that it suffers from the same problems that I ran into the last time I played with LLMs writing queries. Specifically not understanding your schema. It might understand relations but most production tables have oddly named columns, potentially columns that changed function overtime, potentially deprecated columns, internal-lingo columns, and the list goes on. Granted, I was using 3.…

might be possible to solve this with prompt configuration. e.g. you'd be able to explain to the llm all the weird naming conventions and unintuitive mappings
Post reply on HN