Introduction

This question belongs to TensorFlow 1 style execution, where Graph and Session were explicit runtime objects. The core rule is that one Session is attached to one graph, so the practical solution is not "run many graphs in one session" but "manage many graphs in one program."

Understand the graph-session relationship

In TensorFlow 1, a graph stores operations and tensors, and a session executes those operations. When you construct a session with graph=g1, that session expects all executed operations to belong to g1.

1import tensorflow.compat.v1 as tf
2tf.disable_eager_execution()
3
4g1 = tf.Graph()
5g2 = tf.Graph()
6
7with g1.as_default():
8    add_op = tf.constant(2) + tf.constant(3)
9
10with g2.as_default():
11    mul_op = tf.constant(4) * tf.constant(5)

At this point, both graphs exist in memory, but nothing has run yet. Each operation belongs permanently to the graph in whose context it was created.

Use one session per graph

The standard pattern is to create one session for each graph you want to execute.

1import tensorflow.compat.v1 as tf
2tf.disable_eager_execution()
3
4g1 = tf.Graph()
5g2 = tf.Graph()
6
7with g1.as_default():
8    add_op = tf.constant(2) + tf.constant(3)
9
10with g2.as_default():
11    mul_op = tf.constant(4) * tf.constant(5)
12
13with tf.Session(graph=g1) as sess1:
14    print("g1:", sess1.run(add_op))
15
16with tf.Session(graph=g2) as sess2:
17    print("g2:", sess2.run(mul_op))

This is the clearest model because graph ownership stays explicit. It also avoids confusing errors about tensors belonging to another graph.

Why a single session cannot execute arbitrary ops from another graph

Suppose you build add_op in g1 and mul_op in g2. If you then call sess1.run(mul_op) while sess1 is attached to g1, TensorFlow rejects it because the operation does not exist in that session’s graph.

That means a session is not a general execution shell for all graphs in the process. It is a runtime for one specific graph object.

The misunderstanding often comes from running everything in the default graph early on and later introducing custom graphs without updating how sessions are created.

Keep graph construction isolated

Cross-graph bugs usually come from accidentally adding nodes to the default graph. Always use with graph.as_default(): while building each model or computation block.

1with g1.as_default():
2    x1 = tf.placeholder(tf.float32, shape=())
3    y1 = x1 + 10
4
5with g2.as_default():
6    x2 = tf.placeholder(tf.float32, shape=())
7    y2 = x2 * 10
8
9with tf.Session(graph=g1) as sess1:
10    print(sess1.run(y1, feed_dict={x1: 7.0}))
11
12with tf.Session(graph=g2) as sess2:
13    print(sess2.run(y2, feed_dict={x2: 7.0}))

This style is verbose, but it keeps ownership obvious and makes debugging much easier.

Typical use cases for multiple graphs

Multiple graphs in one Python process are most useful when:

• you are loading separate legacy models
• you want isolated variable namespaces
• you are comparing models side by side
• you are migrating old session-based code incrementally

For small scripts, one graph is usually simpler. Multiple graphs add mental overhead, and most new TensorFlow code does not need them.

TensorFlow 2 context

In TensorFlow 2, eager execution is the default and explicit session management is mostly gone. If you are writing new code, prefer Keras models and tf.function rather than introducing tf.Session.

If you are maintaining TensorFlow 1 style code under TensorFlow 2, use tensorflow.compat.v1 and disable eager execution as shown above. That keeps the old mental model intact while running on a newer installation.

Common Pitfalls

The biggest mistake is assuming one session can evaluate operations from any graph that exists in the same process. It cannot. A session is bound to the graph passed at construction time.

Another common issue is forgetting with graph.as_default(): and accidentally polluting the default graph. Later, tensors appear to come from the wrong place and session calls fail in confusing ways.

Developers also mix TensorFlow 1 and TensorFlow 2 assumptions. In TensorFlow 2, eager execution changes how code runs, so examples built around sessions only make sense when you are deliberately using the compatibility layer.

Finally, multiple graphs are not automatically better isolation. They are useful only when the separation is intentional. If you do not need that separation, keeping one graph or using modern TensorFlow APIs is usually the better design.

Summary

• In TensorFlow 1, one session executes one graph.
• To work with multiple graphs, create multiple graph objects and usually multiple sessions.
• Build each graph inside its own as_default() block to avoid cross-graph mistakes.
• Use multiple graphs only when isolation or legacy compatibility makes them worthwhile.
• For new code, prefer TensorFlow 2 eager execution and higher-level APIs over session-based graph management.