prql-query VS zillion

Thank you.

The CLI usability was one of the aims behind [prql-query (pq)](https://github.com/prql/prql-query/). sqlite integration was on the roadmap but unfortunately that project has been largely unmaintained by me for the past 6 months. (This is just referring to prql-query and not PRQL which is under very active development.)

I'm working on a new project which will do exactly this (and a lot more!) which I hope to release next week. I'll drop the link here when that's ready.

As an aside, I could also look at including GQL as a backend in pq (https://github.com/prql/prql-query/) which is my project. It's a bit badly maintained the last few months due to my time constraints but I want to do a big upgrade with the imminent PRQL 0.9 release.

Thanks for the suggestion. I don't think I knew about usql. I completely agree with you and have been working on a cli tool called `prql-query` or `pq` at the command line:

https://github.com/prql/prql-query/

Unfortunately I haven't had much time to spend on it of late but hope to push some updates soon.

I've also been frustrated when testing out tools that kinda keep you locked into one predetermined view, table, or set of tables at a time. I made a semantic data modeling library that puts together queries (and of course joins) for you as it uses a drill-across querying technique, and can also join data across different data sources in a secondary execution layer.

https://github.com/totalhack/zillion

Disclaimer: this project is currently a one man show, though I use it in production at my own company.

https://github.com/totalhack/zillion

Semantic data warehousing and analytics tool written in python. It has experimental/half-baked NLP features to query your warehouse by interacting with the semantic layer with AI, instead of the normal approach of having an LLM write SQL and needing to know your entire schema.

Hey All, I wanted to share Zillion -- an open source Python data modeling and analytics library with experimental natural language features powered by OpenAI, LangChain, and Qdrant. Zillion acts as a semantic layer on top of your data, writes SQL so you don't have to, and easily bolts onto existing database infrastructure via SQLAlchemy Core.

Built it for me, but available to all -- Zillion: a python data modeling and analytics library.

https://github.com/totalhack/zillion

More details/docs can be found in the GitHub repo: https://github.com/totalhack/zillion

Nice work. I had considered implementing something similar in https://github.com/totalhack/zillion down the road, probably as a layer on top.

Zillion: https://github.com/totalhack/zillion

A python data warehousing / modeling / analytics library that can unify multiple datasources and writes SQL for you. It's alpha level at the moment and I just slowly chip away when time allows, though I'm using it in production in another project (which does make money).

This seems fun, but certainly unnecessary. All of those questions could be answered in seconds using a warehouse tool like Looker or Metabase or https://github.com/totalhack/zillion (disclaimer: I'm the author and this is alpha-level stuff, though I use it regularly).

At first glance this seems more confusing, particularly the grouping/aggregation syntax, though I suppose that's something I'd just get used to. Some of the syntactic sugar is nice, but some things are also unlike SQL for no apparent reason which just makes adoption harder than necessary (join syntax for example).

IMO the main selling point would be the "database agnostic" part, but I already achieve that through SQLAlchemy Core and/or a warehouse layer like https://github.com/totalhack/zillion (disclaimer: I'm the author and this is alpha-level stuff, though I use it regularly). It seems like many newer DB technologies/services I'd want to use either speak PostgreSQL or MySQL wire protocol anyway.

The roadmap is worth a read, as it notes some limitations and expected challenges supporting the wide variety of DBMS features and syntax. That said, I can see where this might be useful in the cases where I do have to jump into direct SQL, but want the flexibility to easily switch the back end DB for that code -- that's assuming it can cover the use cases that forced me to write direct SQL in the first place though.