Introduction

“Print the actual query” can mean two different things in SQLAlchemy. Sometimes you want to see the SQL template with bound parameters shown separately. Other times you want a debug-only string with literal values rendered inline. SQLAlchemy supports both, but they are not interchangeable, and the literal form should be treated as a debugging aid rather than a normal execution path.

The Simplest Way to See Executed SQL Is echo=True

If your goal is to watch what SQLAlchemy sends while the program runs, turn on engine echo.

1from sqlalchemy import create_engine, text
2
3engine = create_engine("sqlite:///:memory:", echo=True)
4
5with engine.connect() as conn:
6    conn.execute(text("select 1"))

This logs SQL statements and parameter values as SQLAlchemy executes them. It is the easiest answer when you want runtime visibility without manually stringifying statements.

The benefit is that you are seeing what actually runs, not only what a statement object might compile into abstractly.

Printing a Statement Object Gives Parameterized SQL

If you want the SQL representation of a statement object itself, converting it to a string is often enough.

1from sqlalchemy import select, table, column
2
3users = table("users", column("id"), column("name"))
4stmt = select(users).where(users.c.id == 5)
5
6print(stmt)

That prints SQL with bind placeholders rather than literal values. This is usually the safer and more normal representation because SQLAlchemy is designed around bound parameters.

In other words, if you see a placeholder instead of 5 directly in the string, that is not SQLAlchemy hiding the query from you. That is SQLAlchemy showing the parameterized statement form.

Use Compilation for Dialect-Aware SQL

If you need to see how a statement looks for a specific database dialect, compile it with that dialect.

1from sqlalchemy import select, table, column
2from sqlalchemy.dialects import sqlite
3
4users = table("users", column("id"), column("name"))
5stmt = select(users).where(users.c.name == "Ada")
6
7compiled = stmt.compile(dialect=sqlite.dialect())
8print(compiled)
9print(compiled.params)

This is often more informative than a plain print(stmt) because it gives you both the SQL string and the separate parameter dictionary.

For debugging query shape, this is usually the most useful form.

Render Literal Values Only for Debugging

If you want values inserted directly into the SQL string, compile with literal_binds.

1from sqlalchemy import select, table, column
2from sqlalchemy.dialects import sqlite
3
4users = table("users", column("id"), column("name"))
5stmt = select(users).where(users.c.name == "Ada")
6
7sql_text = stmt.compile(
8    dialect=sqlite.dialect(),
9    compile_kwargs={"literal_binds": True}
10)
11
12print(sql_text)

This is convenient for debugging, logging examples, or copying a query into a SQL console. It is not how you should normally build queries for execution. Bound parameters are the correct default for safety, type handling, and portability.

ORM Style Versus Core Style Changes the Starting Object, Not the Goal

In older ORM examples, you may see session.query(...). In modern SQLAlchemy, you more often start from select(...). The printing concepts stay the same:

• stringification shows parameterized SQL,
• 'echo=True shows executed SQL,'
• compilation gives dialect details,
• and literal_binds is for debug rendering.

So the real skill is understanding what representation you are asking for, not memorizing one object type.

Do Not Use Printed SQL as a Replacement for Proper Logging

A lot of debugging code drifts into production and becomes noisy or misleading. If you need ongoing query visibility, structured SQLAlchemy logging is usually better than sprinkling print statements throughout the code.

Use printed queries to answer a specific debugging question. Use proper engine logging when observability becomes a regular need.

Common Pitfalls

• Expecting print(stmt) to inline literal values automatically.
• Forgetting that parameterized SQL plus a parameter dictionary already describes the real query shape.
• Using literal_binds output as if it were the normal execution form.
• Mixing older session.query(...) examples with modern select(...) code and assuming the inspection tools changed fundamentally.
• Printing SQL strings everywhere instead of using echo=True or proper logging when runtime visibility is the actual goal.

Summary

• 'echo=True is the easiest way to see SQLAlchemy’s executed SQL during runtime.'
• 'print(stmt) usually shows parameterized SQL, not inlined values.'
• 'stmt.compile(...) lets you inspect SQL for a specific dialect and view parameters clearly.'
• 'literal_binds is useful for debugging but should not replace normal bound-parameter execution.'
• Decide whether you want executed SQL, parameterized SQL, or literal debug SQL before choosing the inspection method.