Forem: Dan Shalev

Text2SQL on xxxx's of tables?

Dan Shalev — Mon, 05 Jan 2026 13:56:33 +0000

Text-to-SQL tools work fine in demos. Production with 30K+ tables? They hallucinate relationships and fail in ways you can't debug because the code is closed.

We've shipped several updates focused on solving this.

What's New

React UI Rebuild
Cleaned up the frontend, fixed button logic issues, improved overall UX.

API Release
New API endpoint for programmatic access. Full docs in the repo.

Backend Performance Improvements
Optimized graph generation and query processing for large-scale schemas.

Full Schema Auditability
You can now inspect exactly how your schema gets mapped into the knowledge graph—see the indexing logic, relationship detection, everything.

The Architecture Difference

Vector embeddings can't capture the semantic depth needed for complex relational schemas. QueryWeaver uses knowledge graphs to map table relationships structurally, not statistically. Less hallucination, better accuracy and subsequent queries.

Check it out, it's free: https://app.queryweaver.ai/

Graph to store your security data?

Dan Shalev — Sun, 17 Aug 2025 06:15:15 +0000

The Challenge: You run a multi-tenant security platform and need to ensure full tenant isolation, avoiding customers' data commingling in the same database or needing to spin up a dedicated database for every new customer.

How it affects you: You either introduce risk of data leakage or waste infrastructure resources on isolated stacks.

Why choose graph: You can manage 10,000+ isolated graph tenants per database (across all pricing tiers). Each tenant gets a private namespace and query surface.

🟰 Business impact: Zero tenant data commingling. Minimal DevOps overhead. Efficient scaling of your infrastructure as you grow.

The other 5 reasons are here.

Graph database v4.10 is out!

Dan Shalev — Thu, 12 Jun 2025 14:02:00 +0000

The new release (v4.10.0) is out, and I wanted to share some of the updates and ask for feedback from folks who care about performance, memory efficiency in graph-heavy systems.
FalkorDB is an open-source property graph database that supports OpenCypher (with our own extensions) and is used under the hood for retrieval-augmented generation setups where accuracy matters.
The big problem we’re working on is scaling graph databases without memory bloat or unpredictable performance in prod. Support for Indexing tends to be limited with array fields. And if you want to do something basic like compare a current value to the previous one in a sequence (think time series modeling), the query engine often makes you jump through hoops.
We started FalkorDB after working for years on RedisGraph (we were the original authors). Rather than patch the old codebase, we built FalkorDB with a sparse matrix algebra backend for performance. Our goal was to build something that could hold up under pressure, like 10K+ graphs in a single instance, and still let you answer complex queries interactively.
To get closer to this goal, we’ve added the following improvements in this new version: We added string interning with a new intern() function. It lets you deduplicate identical strings across graphs, which is surprisingly useful in, for example, recommender systems where you have millions of “US” strings. We also added a command (GRAPH.MEMORY USAGE) that breaks down memory consumption by nodes, edges, matrices, and indices (per graph), which is useful when you’re trying to figure out if your heap is getting crushed by edge cardinality or indexing overhead.
Indexing got smarter too, with arrays now natively indexable in a way that’s actually usable in production (Neo4j doesn’t do this natively, last I checked).
On the analytics side, we added CDLP (community detection via label propagation), WCC (weakly connected components), and betweenness centrality, which are all exposed as procedures. These came out of working with teams in fraud detection and behavioral clustering where you don’t want to guess the number of communities in advance.
If you want to try FalkorDB, we recommend you run it via Docker
The code’s also available on GitHub (https://github.com/FalkorDB/falkordb) and we have a live sandbox you can play with at https://browser.falkordb.com. No login or install needed to run queries. Docs are at https://docs.falkordb.com.
Curious to hear from anyone who’s building graph-heavy systems, especially if you’ve hit memory or indexing limits elsewhere. We’re heads-down building and always learning, grateful for any feedback or test cases you throw at us.

How to use a knowledge graph ft. Yohei Nakajima

Dan Shalev — Tue, 27 May 2025 11:29:14 +0000

In this workshop we’ll show 2 live builds: Fractal KG, a UI for building knowledge graphs from a natural language prompt, and VCPedia, a real-time startup intelligence Crunchbase-like platform that is graph powered by hourly Twitter pulls, LLM-based funding-round extraction, and automated newsletters.

Get information: Map out Fractal KG’s architecture: ingestion, embedding, dedupe, hierarchy, and newsletters.
Get inspired: Break down VCPedia’s architecture.
Get started: Integrate FalkorDB for graph queries, multi-tenant support, and setup.

18 June, 2025 ⏰ PDT: 10:00 AM | EDT: 1:00 PM | CEST: 7:00 PM

p.s you can register and we’ll send a recap (even if you can’t attend).

Questions to ask before you build a knowledge graph

Dan Shalev — Tue, 06 May 2025 08:10:45 +0000

Are you planning to develop intelligent chatbots that require advanced understanding and interaction capabilities?
Is your focus on enabling dynamic, complex research endeavors?
Do you want to visualize or monitor asset flows and risks within your organization?
Do you aim to unlock siloed data or enhance connectivity between disparate data environments?

Knowledge graphs help structure information by capturing relationships between disparate data points. They allow users to integrate data from diverse sources and discover hidden patterns and connections.

Why I Fell in Love with Rust Procedural Macros

Dan Shalev — Mon, 05 May 2025 13:14:31 +0000

I consider myself a junior Rust developer. I have been learning Rust for a few months now, and I have thoroughly enjoyed
the process. Recently, we started writing the next generation of
Falkordb using Rust. We chose Rust because of its
performance, safety, and rich type system.

One part we are implementing by hand is the scanner and parser. We do this to optimize performance and to maintain a
clean AST (abstract syntax tree). We are working with
the Antlr4 Cypher grammar, where each Derivation in the grammar maps to a Rust function.

For example, consider the parse rule for a NOT expression:

oC_NotExpression : ( NOT SP? )* oC_ComparisonExpression ;

This corresponds to the Rust function:

fn parse_not_expr(&mut self) -> Result<QueryExprIR, String> {
let mut not_count = 0;

while self.lexer.current() == Token::Not {
self.lexer.next();
not_count += 1;
}

let expr = self.parse_comparison_expr()?;

if not_count % 2 == 0 {
Ok(expr)
} else {
Ok(QueryExprIR::Not(Box::new(expr)))
}
}

Here, we compress consecutive NOT expressions during parsing, but otherwise, the procedure closely resembles the Antlr4
grammar. The function first consumes zero or more NOT tokens, then calls parse_comparison_expr

While working on the parser, a recurring pattern emerged. Many expressions follow the form:

oC_ComparisonExpression
: oC_OrExpression ( ( SP? COMPARISON_OPERATOR SP? ) oC_OrExpression )* ;

which translates roughly to:

fn parse_comparison_expr(&mut self) -> Result<QueryExprIR, String> {
let mut expr = self.parse_or_expr()?;

while self.lexer.current() == Token::ComparisonOperator {
let op = self.lexer.current();
self.lexer.next();
let right = self.parse_or_expr()?;
expr = QueryExprIR::BinaryOp(Box::new(expr), op, Box::new(right));
}

Ok(expr)
}

Similarly, for addition and subtraction:

oC_AddOrSubtractExpression
: oC_MultiplyDivideModuloExpression ( ( SP? '+' SP? oC_MultiplyDivideModuloExpression ) | ( SP? '-' SP? oC_MultiplyDivideModuloExpression ) )* ;

which looks like this in Rust:

fn parse_add_sub_expr(&mut self) -> Result<QueryExprIR, String> {
let mut vec = Vec::new();
vec.push(self.parse_mul_div_modulo_expr()?);
loop {
while Token::Plus == self.lexer.current() {
self.lexer.next();
vec.push(self.parse_mul_div_modulo_expr()?);
}
if vec.len() > 1 {
vec = vec!(QueryExprIR::Add(vec));
}
while Token::Dash == self.lexer.current() {
self.lexer.next();
vec.push(self.parse_mul_div_modulo_expr()?);
}
if vec.len() > 1 {
vec = vec!(QueryExprIR::Sub(vec));
}
if ![Token::Plus, Token::Dash].contains(&self.lexer.current()) {
return Ok(vec.pop().unwrap());
}
};
}

This pattern appeared repeatedly with one, two, or three operators. Although the code is not very complicated, it would
be nice to have a macro that generates this code for us.

We envisioned a macro that takes the expression parser and pairs of (token, AST constructor) like this:

parse_binary_expr!(self.parse_mul_div_modulo_expr()?, Plus => Add, Dash => Sub);

So I started exploring how to write procedural macros in Rust, and I must say it was a very pleasant experience. With
the help of the crates quote and syn, I was able to write a procedural macro that generates this code automatically. The
quote crate lets you generate token streams from templates, and syn allows parsing Rust code into syntax trees and token
streams. Using these two crates makes writing procedural macros in Rust feel like writing a compiler extension.

Let's get into the code.

The first step is to model your macro syntax using Rust data structures. In our case, I used two structs:

struct BinaryOp {
parse_exp: Expr,
binary_op_alts: Vec<BinaryOpAlt>,
}

struct BinaryOpAlt {
token_match: syn::Ident,
ast_constructor: syn::Ident,
}

The leaves of these structs are data types from the syn crate. Expr represents any Rust expression, and syn::Ident
represents an identifier.

Next, we parse the token stream into these data structures. This is straightforward with syn by implementing the Parse
trait:

impl Parse for BinaryOp {
fn parse(input: ParseStream) -> Result<Self> {
let parse_exp = input.parse()?;
_ = input.parse::<syn::Token![,]>()?;
let binary_op_alts =
syn::punctuated::Punctuated::<BinaryOpAlt, syn::Token![,]>::parse_separated_nonempty(
input,
)?;
Ok(Self {
parse_exp,
binary_op_alts: binary_op_alts.into_iter().collect(),
})
}
}

impl Parse for BinaryOpAlt {
fn parse(input: ParseStream) -> Result<Self> {
let token_match = input.parse()?;
_ = input.parse::<syn::Token![=>]>()?;
let ast_constructor = input.parse()?;
Ok(Self {
token_match,
ast_constructor,
})
}
}

The syn crate smartly parses the token stream into the data structures based on the expected types (Token, Expr, Ident,
or BinaryOpAlt).

The final step is to generate the appropriate code from these data structures using the quote crate, which lets you
write Rust code templates that generate token streams. This is done by implementing the ToTokens trait:

impl quote::ToTokens for BinaryOp {
fn to_tokens(
&self,
tokens: &mut proc_macro2::TokenStream,
) {
let binary_op_alts = &self.binary_op_alts;
let parse_exp = &self.parse_exp;
let stream = generate_token_stream(parse_exp, binary_op_alts);
tokens.extend(stream);
}
}

fn generate_token_stream(
parse_exp: &Expr,
alts: &[BinaryOpAlt],
) -> proc_macro2::TokenStream {
let whiles = alts.iter().map(|alt| {
let token_match = &alt.token_match;
let ast_constructor = &alt.ast_constructor;
quote::quote! {
while Token::#token_match == self.lexer.current() {
self.lexer.next();
vec.push(#parse_exp);
}
if vec.len() > 1 {
vec = vec![QueryExprIR::#ast_constructor(vec)];
}
}
});
let tokens = alts.iter().map(|alt| {
let token_match = &alt.token_match;
quote::quote! {
Token::#token_match
}
});

quote::quote! {
let mut vec = Vec::new();
vec.push(#parse_exp);
loop {
#(#whiles)*
if ![#(#tokens,)*].contains(&self.lexer.current()) {
return Ok(vec.pop().unwrap());
}
}
}
}

In generate_token_stream, we first generate the collection of while loops for each operator, then place them inside a
loop using the repetition syntax #(#whiles)*. And that's it!

You can find the full code here

VectorRAG is naive, lacks domain awareness, and can’t handle full dataset retrieval

Dan Shalev — Tue, 29 Apr 2025 12:13:40 +0000

If we were building a GenAI stack today, we'd start with one question: Can your retrieval system handle multi-hop logic?

Trick question, b/c most can’t. They treat retrieval as nearest-neighbor search.

Today, we discussed scaling #GraphRAG at AWS DevOps Day, and the takeaway is clear: VectorRAG is naive, lacks domain awareness, and can’t handle full dataset retrieval.

GraphRAG builds a knowledge graph from source documents, allowing for a deeper understanding of the data + higher accuracy.

X0,000s Ops/sec with Multigraph Topology

Dan Shalev — Wed, 23 Apr 2025 13:44:32 +0000

Yesterday's 'Easily Achieve X0,000s Ops/sec with Multigraph Topology' workshop was awesome. Great questions, too!

We started with a standalone machine with 16 cores = 26k queries per second. We tripled and then doubled the number of cores, and achieved linear scalability.

Recording link: https://www.youtube.com/watch?v=LbeA0-xy1f8

Your GenAI system is only as smart as its retrieval layer.

Dan Shalev — Wed, 16 Apr 2025 11:20:32 +0000

A recent enterprise GenAI survey just confirmed what we’ve been seeing in production:

85% of teams are deploying LLMs
71% are already seeing output risks
99% agree: human oversight is still mandatory

Let’s be clear—this isn’t about model tuning. It’s about retrieval failure at the infrastructure level.

You can’t generate correct answers if your stack can’t model relationships.

You can’t trace decisions if your data lacks structure.

You can’t scale trust if your system hallucinates under pressure.

Here’s what actually works:

Load your structured + unstructured knowledge into a graph database
Model entities, relationships, and policies—don’t flatten them
Route results into your LLM prompt—clean, fast, explainable

That’s how you replace retrieval duct tape with graph-native reasoning.

Exploring advanced RAG & GraphRAG? Start here: https://github.com/FalkorDB/GraphRAG-SDK

Add a Knowledge Graph 3x better

Dan Shalev — Wed, 09 Apr 2025 07:27:09 +0000

If your AI agent doesn’t know when it’s wrong, it doesn’t belong in production.

We reviewed a recent study that tested LLM pipelines against enterprise data environments, benchmarking their performance on enterprise datasets using the Yale Spider schema.

Same model. Same questions. Different architecture.

**Here’s what changed:

**SQL-only → 17.28% accuracy
Add a Knowledge Graph → 3x better
Add ontology-based query checks + repair loop → 72.55% accuracy

That's not incremental progress. That’s a systems-level shift.

Here’s what mattered most:

70% of fixes came from domain constraints in the query body
Most gains showed up in complex schema environments—think KPIs and strategic planning
And when the model couldn’t repair itself? It admitted it with “unknown,” cutting hallucinated outputs by a huge margin

The architecture looks like this:

Ontologies validate logic pre-execution
Knowledge graphs serve as real-time reasoning layers
LLM Repair loops handle failure cases autonomously
FalkorDB is already solving the low-latency challenge here—serving graphs in real time for reasoning-heavy queries.
The lesson: You don’t need smarter prompts. You need systems that can detect when the logic breaks—and fix it before it hits the user.

Vector Recall Reasoning

Dan Shalev — Tue, 01 Apr 2025 13:47:41 +0000

If your GenAI agent can’t reason across relationships, memory, and context—it’s not an agent. It’s a demo.

We came across a research system called DEMENTIA-PLAN—focused on dementia care, but it exposed something bigger: the fatal flaw in most GenAI stacks (source in comments).

Agents that run vector-only retrieval pipelines fail to answer questions grounded in human context.

DEMENTIA-PLAN used multiple knowledge graphs + a planning agent to adapt retrieval in real time. Result? 30% better memory support. 10% higher coherence.

This isn’t just about healthcare.
It’s a blueprint for every agent stack that actually needs to think. If your RAG pipeline gets retrieval wrong, you’re shipping guessware.

What Makes Data AI-Ready?

Dan Shalev — Thu, 27 Mar 2025 09:50:10 +0000

TL;DR: Your AI scaling bottleneck isn't models, it's inconsistent enterprise data—solve it with graph-based pipelines like FalkorDB & GraphRAG.

Gartner: 60% of AI projects fail due to poor-quality data.
Conventional data cleansing can’t handle fragmented enterprise systems.
GraphRAG paired with FalkorDB standardizes scattered data into structured, queryable graphs.

Actionable takeaway: Graph-based solutions directly tackle enterprise-scale AI data chaos.