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

Text-to-SQL is dead, long live text-to-SQL

exasol.com

Post reply on HN
Print view View original

41–50 of 52 posts

Re: Text-to-SQL is dead, long live text-to-SQL

#41

Post by zurfer »

macinjosh wrote: post #39
zurfer wrote: post #31

Earlier quoted context omitted.

Cofounder of one of those analytics agents here ( https://getdot.ai ). The promise of the technology is not that it can deal with any arbitrarily complex Enterprise setup, but rather that you expose it with enough guidance on a controlled and sufficiently good data model. Depending on your use case this can be super valuable as it enables a lot more people to use data and get relevant recommendations. But yeah it's w…

I am working with Databricks' Genies. I have a _very_ complex Enterprise data schema(s). Genies, and from what I can tell, your product work on a set of tables ~20 and expect a well thought out and documented data model. I have hundreds of tables designed by several different teams. I do have decent documentation on the tables but if I had a nice, organized data model I wouldn't need an AI assistant. If I had a perfe…

Well, I can't comment much on Genie, but the core question is always how you scale the complexity.

In Dot, it's divide and conquer. If you have several different teams each of them has to maintain their knowledge base.

A bunch of our customer have less than 10 tables hooked up to Dot, but this data is core to their business and so the analytics agent is really useful. Our most complex setup is on more than 5000 tables, but that was a lot more work to lay out the structure and guidelines.

Also, I don't think all organization are ready for AI. If the data model is a huge mess, data quality is poor and analytics use cases are not mature, it's better to focus on the fundamentals first.

Re: Text-to-SQL is dead, long live text-to-SQL

#42

Post by ROSEDOLA »

zurfer wrote: post #33
bob1029 wrote: post #11

Text-to-SQL is effectively pissing in the wind when we start looking at business value. The trouble is that it works just enough to be dangerous. It is a very interesting idea and can easily consume the resources of a technical team ~indefinitely. One obvious sign we are chasing shiny here is the German-to-SQL example. This is fun, but no one would actually pay for it. I would classify Text-to-SQL as a Schedule I rab…

Germany is the 5th biggest economy in the world, then there is Austria and Switzerland. The claim that nobody would pay for German to SQL seems a bit pessimistic ;) I'd also love to understand better why you think that there is no "acceptable level of value-add in most reasonable enterprises".

Try to sell non-german UI, etc. into the public market… Then you‘ll realize the importance of support for different languages. Honestly, it was surprising how good it worked. But never forget to do your homework first… Or prepare to fail! We tested against several database schemas, but all were well designed. That’s why we stated to achieve reasonable good results. Bad database design and the entire translation process will be anything but acceptable. Utilize all your database offers for commenting or good naming of db objects…

Re: Text-to-SQL is dead, long live text-to-SQL

#43

Post by ghc »

Zambyte wrote: post #30
ghc wrote: post #9

Earlier quoted context omitted.

If history is any indication, you've got it backwards: it's more likely that LLMs will be phased out for SQL.

What history are you considering?

I've only been through a few cycles, but there's three flavors I've seen:

1. Better query language: QUEL, LINQ, etc.

2. Better data model or performance: CouchDB, Mongo, Redis, etc.

3. Better abstraction: Zope, Active Record, et. al.

SQL vendors keep absorbing the differentiating features from other approaches with enough success that they capture most business use cases. That's not to say there aren't successes outside of SQL! But I've seen it claimed SQL will be dead several times over thanks to some new tech and most of the time SQL instead kills that tech or makes it niche.

Re: Text-to-SQL is dead, long live text-to-SQL

#44

Post by munk-a »

xwowsersx wrote: post #28
ErroneousBosh wrote: post #18

But SQL is text, that's the whole point of it. Sure, you have to phrase your question in a way that's a bit like trying to ask a very specific question of an annoying "Self-Diagnosed Internet Autistic" co-worker who can't tell the difference between being "precise" and being "a pedantic pain in the arse", but it is just text. Oh you're upset because SQL isn't in German? Well there's no reason why you can't stick Germ…

Well, of course you're correct that SQL is text, but that's not what the article is arguing about. The point isn't whether SQL is text... it's about the kind of text it is. SQL is a formal language, not a natural one. It's precise, rigid, and requires a specialized understanding of schema, joins, and logic. text-to-sql systems don't exist because people are too lazy to type; they exist because most people can't fluen…

I think it's important to reinforce that SQL isn't an COBOL like attempt at building a querying language out of natural expressions (which you could see if you squint really hard). Instead SQL is a refinement of various querying languages (hence being the standard one) that co-evolved with relational algebra. If you have a chance to learn more within an academic environment courses on relational algebra and the abstract theory of set operations can be invaluable to building a basis for more naturally understanding the intent and tools available in SQL.

Re: Text-to-SQL is dead, long live text-to-SQL

#45

Post by munk-a »

disgruntledphd2 wrote: post #37
lateforwork wrote: post #3

This is solving a problem few people have. They assume your table name, column names and relationships is confidential information. For most people such metadata is not confidential.

> This is solving a problem few people have. They assume your table name, column names and relationships is confidential information. For most people such metadata is not confidential. For most businesses, it really really is. In general, people (businesses) are incredibly sensitive about any possibility of data leakage, even just the metadata. There are lots of companies who would pay for this, and they tend to have…

This would be a (small, granted) red flag for me about a company. As a data architect I work really hard to make sure our model is legible and obvious - the way which the model is adopted to our problem area is certainly a difficult problem that is valuable to have solved. But minor details of that schema should be extremely boring.

Re: Text-to-SQL is dead, long live text-to-SQL

#47

Post by XCSme »

It's hit or miss, but for my product type it worked quite well: https://docs.uxwizz.com/guides/ask-ai

The problem is that often once it starts failing, it rarely recovers from an error, even given the exact error code.

In my dashboard, I added OpenRouter access, so you can quickly swap between models and see which one works best (for your desired accuracy/response time/pricing). Grok 4 Fast is one of the best overall.

Re: Text-to-SQL is dead, long live text-to-SQL

#48

Post by ErroneousBosh »

xwowsersx wrote: post #28
ErroneousBosh wrote: post #18

But SQL is text, that's the whole point of it. Sure, you have to phrase your question in a way that's a bit like trying to ask a very specific question of an annoying "Self-Diagnosed Internet Autistic" co-worker who can't tell the difference between being "precise" and being "a pedantic pain in the arse", but it is just text. Oh you're upset because SQL isn't in German? Well there's no reason why you can't stick Germ…

Well, of course you're correct that SQL is text, but that's not what the article is arguing about. The point isn't whether SQL is text... it's about the kind of text it is. SQL is a formal language, not a natural one. It's precise, rigid, and requires a specialized understanding of schema, joins, and logic. text-to-sql systems don't exist because people are too lazy to type; they exist because most people can't fluen…

> They can describe what they want in natural language ("show me all active users who registerd this year"), but translating that into correct, optimized sql requires at least familiarity, and sometimes expertise

They can describe what they want in natural language only if they have sufficient familiarity and expertise.

If you think that being fluent in a language means you can ask clear and coherent questions in that language, I'd like to invite you to a couple of MS Teams calls this week.

Re: Text-to-SQL is dead, long live text-to-SQL

#49

Post by reverseindex »

sschnei8 wrote: post #12

What is the human need to bash SQL at all costs? At its core, such a simple syntax, yet its so powerful at aggregating/manipulating tabular data and the like. Instead we’d rather declaratively say what we want in a more verbose/disjointed way… fascinating

I used to use SQL very extensively, but then I moved into different roles, and now I always have to look up its syntax, stuff like "how did HAVING work again?", "how do I search for a date two days before today". With Text-to-SQL I can express my query in natural language. Because I have a very solid understanding of relational data models I can craft my prompt very precisely, but without constantly having to go back to the documentation. So at least for casual users it's very helpful.

Re: Text-to-SQL is dead, long live text-to-SQL

#50

Post by snthpy »

unshavedyak wrote: post #21
CodesInChaos wrote: post #17

Earlier quoted context omitted.

For me SQL feels like PHP. Sure it's usable, but it doesn't spark joy. Syntactically PRQL is much simpler, cleaner and more flexible. You simply chain pipeline stages instead of having a single monolithic query statement. Data model wise EdgeQL is close to what I want (links instead of joins, optionality instead of null, nesting support), but it's syntax is almost as bad as SQL.

Oh man, PRQL looks so good. I just wish they had mutation in there too. I don't like the idea of swapping between PRQL and SQL, let alone some complex update statements where i'd rather write the query in PRQL. .. Yea you could argue they shouldn't be that complex for updates though heh.

Yeah, we deliberately left out DML to focus on DQL exclusively. I also find that appealing from a philosophical angle since it allows PRQL to remain completely functional.

I haven't thought about DML too much but what I could envision is an approach like the Elm or React architecture where you specify a new state for a table as a PRQL query and then the compiler computes the diff and issues an efficient update.

For example

    DELETE FROM table_name WHERE id = 1;
would be something like

    table_name = from table_name | filter id != 1
SQL:

    INSERT INTO table_name (id, name) VALUES (1, 'Jane');
PRQL:

   table_name = from table_name | append [{id=1, name='Jane'}]
Update is the trickiest to not have clunky syntax. For example what should the following look like?

SQL:

    UPDATE table_name SET name = 'John' WHERE id = 1;
I can think of `filter` followed by `append` or maybe a case statement but neither seems great.

Any ideas?

Post reply on HN