Whether LangChain’s SQLDatabase supports multiple schemas or only one

OSS Product Help LangChain
1

Hi there, I just want to confirm something. The SQLDatabase class in langchain-community looks to only allow for a single Schema in a DB to be used.

  1. Is this correct? i.e. only one schema can be supported.
  2. Has someone found a work around that requires minimal hand rolling.
  3. Is this feature on a roadmap somewhere or is there scope for community contributions?
2

Hey @robf! I have been using Langchain to pull data out of a multi-schema (and multi-db) environment for about 18 months now and unfortunately, we also ran into this issue. Because we had tight timelines, we opted not to use the community package because one of the things we did was aggressively cut scope of required features.

Ask yourself, what do you need? Models today have gotten very good at tool calling, so you likely only need 1-3 tools which could cumulatively fit into 1-200 lines of easy to understand code.

The tools that we have are:

  • Find relevant tables/queries - Uses a semantic RAG search to find similar queries or tables that can be used to solve a type of problem
  • Describe table - Simply runs a describe table and augments the result. You may not need this
  • Query database - Pretty small shim between the agent and the call to our database connection pool in python. We do use sqlalchemy, but you can use whatever connection you’d like here.
    • We have the most time spent in this tool. We will validate the query in a few ways, like checking for proper joins if we have seen agents struggle to connect specific tables or whatnot, but it started as a direct passthrough. The agent’s credentials are read only, but if your agent should read and write, you may want to use a tool like SQLGlot to confirm that the query meets your requirements.

It sounds like a lot, but you can probably get something going very quickly, actually! You could also create a tool to list all schemas and to list all objects within a schema, but we found agents to be more reliable when the list was maintained by hand. An allow list of tables to use works very well in my experience.

As for your third question, I don’t believe the community repo has a roadmap and that PRs are welcome. If you’d like to add multiple schema functionality, I would create an issue to discuss the ergonomics and proceed from there. The repo belongs to the community and we are able to contribute :slight_smile:

3

SQLDatabase effectively supports only one schema per instance today. For multi-schema setups, create a few small tools (e.g., “find relevant tables/queries”, “describe table”, “query database”) that use fully-qualified names like schema.table and validate SQL as needed. Multi-schema support is not on a published roadmap :pensive_face: .