laminarflow027

Great, thanks for the feedback! I work at LanceDB and will take these points into account (esp. the docs).

Curious what performance issues you faced. Was that in OSS LanceDB? And what were the challenges?

Really cool stuff! Looking at the schema of the financial dataset, though, it's really flat, and it doesn't really leverage the power of the BAML schema format (which excels at representing nested data with fewer tokens than JSON). I suspect that the performance difference with and without the BAMLAdapter would have been more stark if the data model being extracted was more nested.

Great work though, and here's to more experiments of this nature with nested data extraction. Kudos to the BAML team for coming up with such an awesome format, and kudos to the DSPy maintainers for designing such a hackable, usable framework!

The semantic routing step with intent classification and query rewriting was fascinating. The fact that multiple indexes were used is also understated. Is there anywhere one can explore the internals?

To me they seem like the pythonic version of dbt! Instead of yaml, you write Python code. That, and a lot of on-the-fly computations to generate an optimized workflow plan.

Kuzu is an open source, embedded graph database that supports the Cypher query language. We wrote a blog post that serves the dual role of explaining what MCP is and how the MCP server of a database system can be useful. Our demo is based on getting Cursor (or Claude Desktop) to debug a bug in a database (and not in the code itself, which LLMs can already do without any access to the database). The biggest advantage of this way of interacting with a local embedded database like Kuzu, is that a typical 4-5 step debugging session (where the developer would write manual Cypher queries to understand the data), can now be automatically done by an LLM with a single and very simple starter prompt.

Perhaps a lot of similar data engineering/analysis tasks (e.g., ETL, quantifying results, visualization) in the future can be much more easily delegated to LLMs with simple prompts via MCP servers of database systems (possibly multiple of them at the same time). It would be fascinating to see the programming patterns that emerge in this space as MCP clients/servers evolve alongside! We'd love to get feedback and hear more about how otler folks are getting LLMs to do cool stuff using database MCP servers!

Hi, glad to help! I'm a DevRel advocate at Kuzu, and have spent a decent amount of time in other database paradigms thinking about these things. I'm familiar with SurrealDB too.

Although I cannot comment too much SurrealDB's exact capabilities and performance at this point, I can definitely highlight that at the data modeling and query language-level: Kuzu's data model is a property graph model (so an actual "graph" model rather than a multi-model database) and Kuzu implements Cypher as its query language, which is already widely adopted in the industry and is very intuitive to write (for both humans and LLMs).

Although Surreal DB does indeed offer an embedded mode, Kuzu is by design 100% embedded, is super-lightweight and can run natively in many environments, such as browsers, Android applications, AWS Lambda (serverless) and we're especially designed to be a VERY Python-friendly graph database that integrates with pretty much all well-known Python libraries. Because of its columnar storage layer, Kuzu can seamlessly read and write different data formats, such as Panda/Polars DataFrame, Arrow tables, Iceberg or Delta Lake tables and seamlessly move data between advanced graph analytics libraries like NetworkX. For anything related to graph computation, Kuzu is likely to have all the right tools and utilities to help you solve the problem at hand.

In my opinion, it's a myth that databases are heavy, monolithic pieces of software, and hopefully, using Kuzu will demonstrate that it's totally possible to have data in your primary store but seamlessly move it to a performant graph storage layer when required, and move the results back with minimum friction and cost. Hope that helps!

Your concern makes sense, but in the demo we show, all your private data AND the graph database AND the LLM (basically, everything) is confined to your client session in the browser, and no data actually ever leaves your machine. That's the whole point of Wasm!

The graph that you build is more for your own exploration and not for sharing with the outside world.