louisjoejordan

We've been focusing on the core VS Code extension and haven't released sharing yet. The plan is to provide a Vercel-like experience for deploying and sharing graphs.

People will be able to connect their GitHub repositories, deploy dashboards, and share them via our website. The interface will allow switching between branches and time-traveling between different states of the dashboard.

Here's a preview: https://www.youtube.com/watch?v=MD6In-iUd9g

Hey! We killed the auth flow from our extension, we used it to get an idea of how many people are using it. The extension works entirely local and connects to your database through your machine. So there's no need to self-host anything!

The biggest difference I see (though I'm not super familiar with Plotly) is that we define data transformations in SQL, while Plotly uses Python. One benefit of SQL is that it provides the advantage of tracing data lineage from source to visualization, which gives you visibility into data dependencies - something that Python code in Plotly Dash doesn't offer.

Appreciate your feedback and guidance.

I was just at the Click-house office a few weeks ago - this is a really good idea.

Great! Feel free to reach out to me with any questions.

Appreciate the kind feedback! Curious to know if org-mode is still actively maintained.

You're spot on that BI adoption is largely a social challenge. Our thesis is that by defining the entire journey from source to viz as code, we create a structured foundation that LLMs can build upon, democratizing access to the transformation layer for non-engineers in a way that point-and-click BI tools can't.

This is awesome! Great to see this project still alive after so many years :)

Hey! OP here. This made my day, thank you!

We do if you use DuckDB and you pull data from your data sources through DuckDB. DuckDB can act as a single interface between multiple data source types. Feel free to DM me with any more questions. around your specific use-case and I can help.

Hey! We love Redash too. Where Quary is different is that we have more of an emphasis on Transformation. This means people can split out complex SQL blocks into modular, reusable components which improves data lineage (how the data flows from table to visualisation).

Dbt makes transformations modular and easier. It applies software development methods to the T of ELT.

Hey! OP here. This is really good feedback thank you.

Hey, great question ... Again another tool we love. A few key differences:

- Visual studio code as the editor through and through

- Dashboards are fully defined in code Quary which is different to Rill

- At its core our architecture is also very different, Rill is built on top of Duckdb for that interactivity which can call out to other databases whereas we can call other SQL databases without everything going through DuckDB.

Big fans of our fellow YC mates at Lightdash!

There are some core differences that make our product feel quite different:

- Lightdash isn't Lightdash without dbt so you always have that divide even though they have done a fab job of minimizing it.

- The editor for us is in Visual Studio Code which means you don't have that jump and can iterate all together.

- Every thing is version controlled as a file in your repository which means you can add those engineering practices to the dashboards/charts themselves.

Hey! OP here, I don't have a clear answer for this yet. We're exploring ways to make Quary more extensible. We are focusing on the core piece first, happy to chat to hear more about your specific use-case.

Hey! Thanks so much, really appreciate the feedback

Hey, OP here. We love what dbt has done for transformation-layer engineering. But we often see companies still struggling with a mess of unstructured dashboards, even with solid dbt models underneath.

The problem is that dbt models and BI dashboards are often managed by separate teams. Quary brings the two together, letting engineers define reusable models and build well-structured dashboards on top of them in one cohesive, code-first environment.

Hey! Louis here from https://www.quary.dev, we needed a SQL linter that runs natively in the browser, without the need to install Python. So we built it and open-sourced it for the community

It is currently 2x SLOWER the current de-facto SQL linter (https://sqlfluff.com) but we haven't even thought about speed yet. We look forward to your comments and suggestions.