Show HN: Query Your Sheets with SheetSQL (sheetsql.io)
I've developed a tool named SheetSQL that allows you to query, join, export, and schedule your queries to Google Sheets through a straightforward SQL interface in the browser.
This tool is a simple, first iteration of the idea, so I'm eager to receive feedback on it. You can contact me at taras [at] sheetsql.io :D. I'd love to find out if it could be useful for folks out there!
As someone working in fintech, I constantly deal with sheets and often find it challenging to perform seemingly simple tasks like JOINs natively. However, I'm familiar with SQL, which inspired the creation of SheetSQL. It's designed to assist those who use sheets daily and have some SQL knowledge, making operations across multiple sheets and worksheets as easy as if they were interacting with a Postgres database.
For those interested in the technical details, the engine powering the queries in the background is DuckDB. Therefore, you can expect support for all syntax from the latest version of DuckDB :)
Cheers,
72 comments
[ 1.4 ms ] story [ 218 ms ] threadHonestly, I wouldn't worry about it. If your tool is useful to people, I think your query limit on the free-tier will be enough.
However, charging for queries would be like ChatGPT charging in tokens — yes, it's understandable, but non-intuitive. And very product-, not user-driven.
I'd rather keep it simple in terms that a user can understand. Really like how you set it up right now — makes it easy to say yes.
The _enterprise_ game is the one where you will make the real money: Teams, Management, Integrations, Access Rights, Billing cycles, Onboarding, etc.
Or the second tier should still be capped. But that looks wrong feo marketing point of view.
Now, I do believe that I may just increase the free allowance, and maybe if I see people that want to power use normal queries and have maybe a few scheduled ones have an mid tier plan (or even on demand) that allows more queries and a few schedules.
And eventually move the PRO to be a really PRO plan.
Often previous tech people had to built internal CRUD apps with Byzantine interfaces that trafficked in JSON or YAML files.
But being able to make changes to our app, or import/export data, and all via making changes to a google sheet—this feels like magic.
But yes, for the inevitable times when they get it wrong, you just need some robust alerting system. Having it email/text me when anything goes wrong turned out to still be easier than writing our own CRUD app or fancy interfaces.
Where are you storing the structure of the sheet though? Is it re-evaluated on each query? I am thinking about cases where a column header is renamed or the data types in a column are changed?
It's using a temporary cache that re-uses the latest data from the sheet (checking if it was updated) so that's why the subsequent queries should be much faster than the initial one.
Now about the headers, it's indeed an issue that I need to figure out, as there are some sheets that have weird structures and it would be nice to find an easy UXsy way to preview the sheet data and say "select from this range" or "these are the headers".
Indeed. Defining the UX when the only UI you have is a SQL query is a bit challenging.
Very impressive project indeed and solves a real problem a lot of people and companies have. I wish you luck.
Thanks for the comment!!
The extensibility system also lets you show a modal dialog, which we use for previewing API calls to third party HTTP servers -- sounds like a similar thing could work well for you, too.
You could also look at supporting named ranges if you don't already, so people can refer to a range as `FinanceData` instead of `Sheet 1!A3:F90`
Still, if it were to be extended to a full query language with good ergonomic it would be amazing.
1. It's writing a query in a single row cell which is hard from a UX perspective 2. SheetSQL offers you a way to cross join sheets as if those where tables, even between worksheets, which is something that is not supported natively 3. Full DuckDB SQL support, so you can use advanced functions like PIVOT or window functions
Is there a rate limit?
Will changed to the sheet instantly go live? Or is that a manual process to clear cache?
Also, in theory right now once you use a sheet once it will cache the version so that subsequent queries are faster, and in theory if you change the sheet it will check for that and use the live data if it got updated in the meantime.
Nevertheless, it might take a minute or so sometimes.
For someone more techie probably could work, as you could dump the data to sqlite and then query it. But if you want to have it dynamically and from sheets in real-time probably it would be harder to handle this way.
This is the exact reason I built TextQuery [2], which solves a similar problem as OP's. I just wanted a simple app where I could drop a CSV and start SQL querying it, without creating schemas or writing code/commands.
[1]: https://news.ycombinator.com/item?id=8863
[2]: https://textquery.app/
edit: looks like sphinx
1 - https://github.com/turbot/steampipe 2 - https://github.com/turbot/steampipe-plugin-googlesheets
1 - https://steampipe.io/docs/guides/caching 2 - https://flowpipe.io/docs/flowpipe-hcl/trigger/query 3 - https://github.com/turbot/flowpipe
You get a lot of this for free in duckdb. e.g. if you run the query below from the duckdb CLI, it'll query the sheet[0]:
We use duckdb under the hood at my new company (https://www.definite.app/), so we get this same sort of functionality for free.0 - https://twitter.com/thisritchie/status/1767922982046015840
I think it is a pain point for some people, and it's great to see other teams working on similar products and being based on the same tech.
I'm not getting a quota error despite not using it all day:
> Could not run query
> Error: Monthly free usage of 100 exceeded,
It's saying I've used 188 out of 100 which is odd. I haven't used 188 - more like 15.
Earlier I was trying a query like:
> SELECT * from <table> where Status="Complete";
And it was complaining that Complete wasn't a valid column... (rather than Status...) I also had weird issues trying to replace * with an actual column name. The autocomplete went crazy.
Not sure if it makes a difference but I'm a stubborn Firefox user.
Now about the query, DuckDB works in the following way, the query you sent should be written like
> SELECT * from <table> where "Status" = 'Complete';
Now this is because the `"` is used for the table and column names, and the `'` is used for raw string. See more here https://duckdb.org/docs/sql/introduction#querying-a-table which might be a bit different from other SQL database engines.
And finally, regarding the autocomplete, it indeeds tries to autocomplete in a too verbose way, which is something I'll try to improve.
Thanks for reaching out, and hopefully this can help you try it out!
https://www.wheremoneygo.com barely has a database, and bedsides protecting the Google access keys has minimal privacy/security risk.
The main risk, and something I've only seen once, is a corrupted database on the Google Sheets side. Since I don't want to keep backups of peoples sheets, if something goes wrong on the Google-side the entire database could be lost.
Here's an example for querying a Google Sheet:
https://sql-workbench.com/#queries=v0,SELECT-*-FROM-read_csv...
The same query in SheetSQL
https://ibb.co/dDdZ0vC
All the best :)
The trick (and I assume you’ve found ways around this) is dealing with the flaky Sheets API that throws a 500 error what feels like 1% of the time, and also deciding when/where/how to enforce the SQL data types and column headers. I made a config layer for the latter.. the interface to which is also a Sheet, lol.
[1]: https://learn.microsoft.com/powershell
[2]: https://github.com/dfinke/ImportExcel