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

Show HN: We open sourced our entire text-to-SQL product

github.com

Post reply on HN
Print view View original

131–140 of 147 posts

Re: Show HN: We open sourced our entire text-to-SQL product

#131

Post by threecheese »

edmundsauto wrote: post #127
saigal wrote: post #120

Earlier quoted context omitted.

yes. some want BYOC solutions. others don't want to even be perceived as being used to train an LLM. not to mention CCPA, GDPR, etc etc etc. lots of questions around what data is being sent to the LLM, or just schema.

Interesting. So by open sourcing you think companies can self host and it negates some of these issues? Or is your goal into increase future contributions to keep the project alive and developing? What % of the NL -> SQL problem is solved in the current version? Ie is this something ready for some type of prod work now, or is it “in 2-3 years we’ll be there”?

Not OP, but there was an EHR SaaS company on HN a day or two back with a similar proposition: it’s open source, so it can be independently verified from a security perspective. It was interesting to me because the code was unusable to normal folks, and even other companies - one of the founders described their moat being the trouble of actually integrating with the ecosystem, and weren’t worried about competitors using it. It really hammered home to me how open source is more and more a marketing lever lately.

Re: Show HN: We open sourced our entire text-to-SQL product

#132

Post by aazo11 »

BossingAround wrote: post #94
saigal wrote: post #24

Earlier quoted context omitted.

great question, and the one that we get the most :-) this is precisely why we created Dataherald. Off the shelf LLMs can handle a single table and simple questions. Dataherald's quest is to ultimately provide enterprise-grade text to SQL, where complex schema and joins are present. it does take some training, but we've found that it can handle situations such as the one you mention above.

Perhaps orthogonal problem - imagine you join a new company that has an enterprise product with hundreds of tables. Is there a way to connect Dataherald to my DB, and ask basic questions about the DB? E.g. "where are stored records related to X".

Yes when you connect Dataherald to a DB it scans it and you can do exploratory queries.

Re: Show HN: We open sourced our entire text-to-SQL product

#133

Post by aazo11 »

edmundsauto wrote: post #127
saigal wrote: post #120

Earlier quoted context omitted.

yes. some want BYOC solutions. others don't want to even be perceived as being used to train an LLM. not to mention CCPA, GDPR, etc etc etc. lots of questions around what data is being sent to the LLM, or just schema.

Interesting. So by open sourcing you think companies can self host and it negates some of these issues? Or is your goal into increase future contributions to keep the project alive and developing? What % of the NL -> SQL problem is solved in the current version? Ie is this something ready for some type of prod work now, or is it “in 2-3 years we’ll be there”?

There are organizations using Dataherald in production right now.

The latency is ~20-30s and it takes some set up, so as long as those are not blockers it can be used in prod.

Re: Show HN: We open sourced our entire text-to-SQL product

#134

Post by aazo11 »

pamelafox wrote: post #124

It looks like the supported vector DBs are Pinecone and Astra. Have you looked into Postgres with pgvector? I’ve started experimenting with building RAG flows for pgvector, works fairly well.

Right now the supported Vector stores are Chroma (which you can self-host), Pinecone and Astra. Adding a new vector store is quite easy: you just need to extend the VectorStore class (https://github.com/Dataherald/dataherald/tree/main/services/...) and set it as the Vector store module to be used in the environment variable https://github.com/Dataherald/dataherald/blob/main/services/...

Re: Show HN: We open sourced our entire text-to-SQL product

#135

Post by npsimons »

This is awesome! While I'm nowhere near being able to leverage this right now, I am currently going through the painful process of "databasing" raw documents into SQL, and I can tell you that perhaps the hardest part is getting the schema correct; as you put it "natural language can often be ambiguous". Even worse, is just the squishiness of things never originally intended to be specified for software.

Communication always has been, and continues to be, the hardest part of software development.

Re: Show HN: We open sourced our entire text-to-SQL product

#136

Post by saigal »

edmundsauto wrote: post #127
saigal wrote: post #120

Earlier quoted context omitted.

yes. some want BYOC solutions. others don't want to even be perceived as being used to train an LLM. not to mention CCPA, GDPR, etc etc etc. lots of questions around what data is being sent to the LLM, or just schema.

Interesting. So by open sourcing you think companies can self host and it negates some of these issues? Or is your goal into increase future contributions to keep the project alive and developing? What % of the NL -> SQL problem is solved in the current version? Ie is this something ready for some type of prod work now, or is it “in 2-3 years we’ll be there”?

For companies that are willing to put in some effort, the self hosting option is a great one. There are certain use cases where this works now, and is already in production. These tend to be use cases with some constraints and don’t deal with very sensitive data.

Re: Show HN: We open sourced our entire text-to-SQL product

#137

Post by panarky »

TheRealPomax wrote: post #33
saigal wrote: post #20

Earlier quoted context omitted.

the target audience is developers who wish to embed text to SQL functionality into their own products. the target audience is less the 'internal use case' (i.e. a data analyst) and more about letting external users do things they couldn't do before. a good example is payroll software where this type of technology can allow users to pull reports.

With what level of accuracy? And what guarantee of correctness? Because a report that happens to get the joins wrong once every 1000 reports is going to lead to fun legal problems. You still need someone who understands why you should use which approach to get the data you need without getting completely wrong numbers back that _look_ perfectly fine but reflect fantasy, not reality.

Getting joins wrong once in 1000 queries would beat 99.9% of experienced data analysts.

Our standards for AI are too high.

If an autonomous car causes one wreck per ten million miles, people set the cars on fire.

When someone finds an LLM that suggests eating a small rock every day, that anecdote is used to discredit all LLM results.

This shit makes errors. But what is the alternative? Human analysts who get joins wrong four times in ten? Human drivers who cause wrecks 30 times per ten million miles? Human social media recommendations about nutritional supplements?

Re: Show HN: We open sourced our entire text-to-SQL product

#139

Post by saigal »

Kiro wrote: post #110
nicoburns wrote: post #70

Earlier quoted context omitted.

But who wants text-to-sql in products that they use? You wouldn't be able to trust the results. So what is it useful for? Of course you could learn to check the output. But then you could just learn SQL. I know dozens of not particularly technical people (certainly not software developers) who have learnt enough SQL to be useful over a couple of days.

The demand is huge. Accuracy is less important because the alternative is being completely in the dark or wait for a developer to get the data for you. In my experience people want to quickly get a ballpark number before they dig deeper. I agree that you should just learn SQL but that doesn't change the fact that a lot of companies want this right now. SQLAI claims to have hundreds of thousands of customers.

Couldn’t agree with this more. Exactly.

Re: Show HN: We open sourced our entire text-to-SQL product

#140

Post by roughly »

saigal wrote: post #24
thedynamicduo wrote: post #21

This looks really cool, can't wait to check it out. The problem I've seen with other tools I've tinkered with is that they do well with simple stuff like: "what are my latest orders" -> select * from orders where user_id=x order by created_date But really struggle when you have a complex schema that requires joins, and basically has no support when you are describing something that needs outer joins or the like. Woul…

great question, and the one that we get the most :-) this is precisely why we created Dataherald. Off the shelf LLMs can handle a single table and simple questions. Dataherald's quest is to ultimately provide enterprise-grade text to SQL, where complex schema and joins are present. it does take some training, but we've found that it can handle situations such as the one you mention above.

So from the look of this, you’re open sourcing all of the agent/usage code, but I’m guessing you’re keeping the trained model in-house, so that becomes the value prop for Dataherald the product - the trained LLM?
Post reply on HN