Show HN: Query your database using plain English, fully on-premises (vizly.fyi)
My friend Sami and I recently built Vizly, a Mac application that allows anyone to query their databases using plain English.
Vizly is built on Llama 2, llama.cpp, and runs fully on-prem (edit: meaning everything is local and your data never leaves your own computer).
We are running two Llama models, one for natural language to SQL translation, and another that uses the results from the SQL to render visualizations. That means there are no external APIs and all the AI models are running locally on your MacBook.
We tried to make Vizly very easy to share as well. Every Vizly instance creates a share link that can be accessed by anyone on the same network as you. Just send the share link to anyone on the same network and they will be immediately able to run AI-powered queries, hosted from your device.
Vizly previously used to be a hosted solution for querying CSVs and now we are on-prem specifically focussed on databases.
Would love if you could try it out and give us any feedback!
55 comments
[ 4.2 ms ] story [ 107 ms ] thread1. Your website doesn't say which DBs you support.
2. What information do you feed the model to determine how to map from English language queries to SQL? Do you just use the schema from information_schema? Do you use any DB object comments (e.g. we annotate all our tables, views and columns with Postgres comments)? Do you sample any actual data?
Thanks
The database connectors we support right now are: - MySQL - Postgres - Snowflake - Apache Impala
In terms of how we map English queries to SQL, we only look at the schema at the moment.
We have the ability, and have experimented with adding enriching information such as sampling the data, as well adding comments to the schemas.
We've noticed that both approaches actually do increase accuracy but just to keep things simple for the initial release we haven't added those yet.
Just so I know for future reference, what system do you use for DB object comments?
Thanks again for your feedback!
Postgres supports this natively (there was actually an earlier HN post today about "little known Postgres features" that mentioned it): https://www.postgresql.org/docs/current/sql-comment.html
We use it extensively because tools like Datagrip will display these comments in the schema browser. It would be pretty trivial I imagine to update your tool to pull these comments from the Postgres schema.
"Lesser Known Postgres Features (2021)":
https://news.ycombinator.com/item?id=37309309
So anything that makes using CSV files easier with your product is likely going to be a welcome change for a lot of people.
Realistically, your database engine can probably ingest the CSV file in a simple import statement, so you're likely 98% done already with this. :)
I use BigQuery as the database, which is a competitor to SnowFlake which you already support. I also already use ChatGPT-4 a lot nowadays to create and edit the SQL queries (although they can sometimes be so large that ChatGPT can't cope with them so I sometimes use cut-down/contrived examples to write chunks of a query then construct a much bigger query from those smaller examples).
So you could replace my job if you could allow people to name their data warehouse provider of choice, drag and drop umpteen CSV files into it, write some instructions like "Give me a CSV file with all the BLAH matching BLAH" or "Create PDF documents with BLAH information in them" and get the outputs they need on the other end.
I was wondering if this would also be supported for no-SQL databases like Mongo?
Also a little sandbox to play with it would be nice. For example, you could have a small table of weather data from a random city, and people could then query something like "How many days in 2022 was the daily high for Los Angeles above 100 degrees?" Of course, this might be a lot of work as you would have to have it run on the backend and then return the results to the frontend.
Thanks a lot for the feedback!
It's still very valid feedback, on our side we should make the permissions of each user very clear and make it clearer that we only do select queries. Will make sure to make those changes! Thanks for the feedback!
And providing the user interface to do that
I think you have a great point though, this should be made much clearer so users can build trust in using the product. Thanks a lot for the feedback!
So it will select from functions?
SELECT delete_all_from_table('users');It is correct to say that an application runs 'on premise', if it can be self-hosted (often 'on premise' or 'on prem' does not literally mean that the server is on the same premises as the company's headquarters, just that the company manage the server).
The word "premise" is misused in "on premise" speaking of computers running at a owner's location. I don't think the distinction of it referring to a literal location or metaphorical location (managed by an owner at a different location) matters.
While this might change over time and with on-going vernacular usage, but as of now: our industry is misusing the word. Including myself (until now).
The use of 'on-premise' rather than 'on-premises' even in formal texts is at least 200 years old (examples below). How much time should it take for us to accept "on-premise", rather than "on-premises"?
(https://www.google.hu/books/edition/Records_and_Briefs_of_th..., https://www.google.hu/books/edition/Documents/3jIbAQAAIAAJ?h..., https://www.google.hu/books/edition/Council_Proceedings/rLro...).
The landing page focuses on ease of use and privacy (awesome!). But is this a tool I can use to make critical informed decisions or something where I am willing to trade correctness for ease of use?
Being able to click into a chart and see the generated query along with explanation of the intent of each step of the query would go a long way in building trust in the result.
I hope you're referring to 'someone can eventually get killed by this'.
For the love of humanity, please don't use this in any real world case. Llama will generate mistaken queries in at least single-digit % of cases (optimistically).
If you use this, it's a matter of time for a mistaken query to coincide with very bad timing and context, leading to bad outcomes.
> any real world use case
I can see plenty of real world use cases where a trade off between ease of use and accuracy might be acceptable, there are a plethora of technical solutions to improving/checking accuracy and workflows can be designed to prevent “bad outcomes”. Certainly enough potential here for a set of plucky founders to give this a crack.
Any examples come to mind?
I can't see a case when data retrieved from a database will be wrong, someone will do something with it, and it's fine.
I get this product looks like it’s single db, not yet connectable to knowledge systems, file stores etc. but it doesn’t take much imagination to see it going there. Having an interactive company brain would be useful even if you don’t want to trust it to answer more specific questions like “what percentage of our customers are x”.
And what happens when you send the wrong message with sensitive data to the wrong Brian because of that?
Otherwise the idea is great, now please someone create this for Splunk...
There are some non-developer users who can run queries on a read-only copy of the database. However, for anything complicated they usually have to ask the developers whether the query they have written actually matches the English description of what they want. Sometimes it does, but often there’s some nuances that their query doesn’t capture.
Most of the expense of getting this data isn’t writing the query, therefore, it’s validating it.
If you need the help of a tool like this to write your query, how are you possibly going to know whether the results are what you want without taking the generated query to an expert?
We're in for a scary wild ride.
Garbage in - garbage out.
Same concern I have with all the companies using LLM for searching company documents.
Most of the data I have seen at the corporate level does indeed have nuance to it and is often not as clear as just the named column. Usually not much of any documentation and that is always a tough problem to solve. Imo it’s about how to maintain knowledge bases properly, it’s a tough but to crack.
that’s the gamble all of these “natural language” tools are making. sell to people that aren’t experts, attempt to deflect criticism from those that are. what’s a $20k subscription compared to a $200k person?
what comes next depends on the company. some will invest the money in the product to make it more useful. others will search for more fools.
most importantly, nobody wants to be left behind. there’s a lot of products that need more time in the oven, but that’s never stopped a good salesperson.
It is actually nice to see the abbreviation “on prem” being used, because at least the error is abbreviated away!
But it does sound like an interesting project!