Best practice for mapping LangGraph threads to users (multi-tenant / production)

I’m building a production chat app with multiple users, and I’m trying to understand the recommended way to associate LangGraph threads (or LangSmith Threads) with a user_id. I used this tutorial to put something together quickly and now I want to extend it to multiple users.

My production requirement is:

  • many users (multi-tenant)

  • each user may have multiple conversations

  • I need to ensure conversation state is isolated per user

  • ideally I can query/filter traces by user in LangSmith too

Questions:

  1. Is there a built-in concept of user_id / tenant in LangGraph threads, or is the expected approach to map (user_id → thread_id) in my own DB?

  2. If the second approach is recommended, should I generate thread_id as a UUID, or something like f"{user_id}:{conversation_id}"?

  3. Is there a recommended way to attach user_id into LangSmith tracing metadata so I can filter traces by user (without merging state between users)?

hi @eight

is that helpful? Multi-tenant / per-user checkpoint querying with AsyncPostgresSaver - #2 by pawel-twardziak
Or are you looking for something else?

For filtering/querying in LangSmith you may want to use metadata too I think

Thank you so much for a prompt response @pawel-twardziak. I looked up metadata and found this tutorial very helpful. I was able to assign user ids using metadata and filter based on the ids for in-memory deployment.

Two follow up questions:

  1. Is authorization only enable for enterprise license for cloud deployment. Is it possible to enable authorization for self hosted cloud deployment?

  2. Are there any APIs/decorators for interacting with Memory Store similar to the ones for Threads?

Thanks.

hi @eight

afaik:

  • Auth / authorization: platform feature (SaaS + Enterprise self‑host), not something you can fully turn on for the basic in‑memory dev server.
  • Memory Store: yes, there are APIs (InMemoryStore / MemoryStore and the Store interface) and you can compile graphs with store=..., but today they’re method‑based rather than decorator‑based; platform deployments manage the underlying store for you.

Very helpful. Thank you