Show HN: ShapedQL – A SQL engine for multi-stage ranking and RAG (opens in new tab)

All of the retrievers do support pre-filtering, you just add the where clause within the retriever function. We're working on more query optimization to make this automatic also.

1) So we do actually have a python and typescript API, it's just the console web experience is SQL only as it feels the best for that kind of experience. The most important thing though is that it's declarative. This helps keep things relatively simple despite all the configuration complexity, and is also the best for LLMs/agents as they can iterate on the syntax without doc context.

2) Yeah exactly, joins is something we can't do at the moment, and i'm not sure the exact solution their honestly. Under the hood most of Shaped's offline data is built around Clickhouse, and we do want to build a more standard SQL interface just so you can do ad-hoc, analytical queries. We're currently trying to work if we should integrate it more directly with ShapedQL or just keep it as a separate interface (e.g. a ShapedQL tab vs a Clickhouse SQL tab).

3) We didn't really want to create a new SQL dialect, or really a new database. The problem is none of the current databases are well suited for search and recommendations, where you need extremely low latency, scalable, fault-tolerance, but also the ability to query based on a user or session context. One of the big things here is that because Shaped stores the user interactions alongside the item catalog, we can encode real-time vectors based on those interactions all in an embedding query service. I don't think that's possible with any other database.

4) I haven't looked into mindsdb too much, but this is a good reminder for me to deep dive into it later today. From taking a quick pass on it, my guess is the biggest difference is that we're built specifically for real-time search, recommendations and RAG, and that means latency, and ability to integrate click-through-rate models and things becomes vital.

Thanks so much for the playground syntax, have some follow up questions but i'm going to pm you if that's okay. Agreed on the being able to see which columns exist.

Someone shared with me these the other day and we're inspired to add more remote LLM calls directly into ShapedQL now: https://github.com/asg017/sqlite-rembed https://github.com/asg017/sqlite-lembed

Curious what relational database do you @refset use? Is the code open source? Is the engine from scratch? What general dialect does it support?

Cheers!

For the cloud platform though (console.shaped.ai), i'd recommend just testing with some synthetic or deanonymized data or our demos and then if you're interested in BYOC reach out after April!

Thanks for the feedback on the privacy policy, let me see if we can get that changed. For what it's worth we don't share personal information with anyone, this is likely just overly defensive legal writing on our part.

E.g imagine trying to build a feed with pgvector, you need to build all of the vector encoding logic for your catalog, then you need to build user embeddings, the models to represent that and then have a service that at query time encodes user embeddings from interactions does a lookup on pgvector and returns nearest neighbor items. Then you also need to think about fine-tuning reranking models, diversity algorithms and the cold-start problem of serving new items to users. Shaped and ShapedQL bundles all of that logic into a service that does it all as one in a low-latency and fault-tolerant way.

To put it in the perspective of LLMs, LLMs perform much better when you can paste the full context in a short context window. I've personally found it just doesn't miss things as much so the number of tokens does matter even if it's less important than for a human.

For the turbopuffer comment, just btw, we're not a vector store necessarily we're more like a vector store + feature store + machine learning inference service. So we do the encoding on our side, and bundle the model fine-tuning etc...

> isn't really a selling point when an LLM can do it in a few seconds.

this is not my area of expertise, but doesn't that still assume the LLM will get it done right?

This idea that it no longer matters because Ai can spam out code is a concerning trend.