YSQL Connection Manager (YCM) is easy to enable and just as easy to accidentally connect around it during testing. That’s not misuse; it’s a natural outcome of how YugabyteDB exposes two different YSQL ports when YCM is enabled.
Under the hood, YCM runs as its own Odyssey-based connection manager path, separate from the PostgreSQL backend process. Both can accept connections successfully, but they behave very differently.
This tip shows the fastest, zero-guesswork way to prove whether your current session is using YSQL Connection Manager, explains why the answer flips by port, and shows how to verify what’s actually running on the node.
✅ The fastest proof: SHOW yb_is_client_ysqlconnmgr
From any YSQL session:
SHOW yb_is_client_ysqlconnmgr;
Results are definitive:
No logs. No metrics. No guesswork.
There are a few additional ways to check the value of yb_is_client_ysqlconnmgr:
SELECT current_setting('yb_is_client_ysqlconnmgr');
SELECT setting, short_desc FROM pg_settings WHERE name = 'yb_is_client_ysqlconnmgr';
🧪 Example: single-node yugabyted
Start YugabyteDB with YCM enabled:
yugabyted start --tserver_flags="enable_ysql_conn_mgr=true"
Now compare the two ports:
# YCM (client-facing)
ysqlsh -h 127.0.0.1 -p 5433 -c "SHOW yb_is_client_ysqlconnmgr;"
# Direct PostgreSQL backend
ysqlsh -h 127.0.0.1 -p 6433 -c "SHOW yb_is_client_ysqlconnmgr;"
Example:
[root@localhost ~]# # YCM (client-facing)
ysqlsh -h 127.0.0.1 -p 5433 -c "SHOW yb_is_client_ysqlconnmgr;"
yb_is_client_ysqlconnmgr
--------------------------
on
(1 row)
[root@localhost ~]# # Direct PostgreSQL backend
ysqlsh -h 127.0.0.1 -p 6433 -c "SHOW yb_is_client_ysqlconnmgr;"
yb_is_client_ysqlconnmgr
--------------------------
off
(1 row)
Same node. Same DB. Same user… but, Different port → different connection path.
🚀 One-liner: show both ports from live processes
This inspects the running processes and prints the ports side-by-side. It works whether PostgreSQL was started with -p or only exposes the port via its socket path (-k):
echo "YCM port: $(ps -ef | grep '[y]b-tserver' | sed -n 's/.*--pgsql_proxy_bind_address=[^:]*:\([0-9]\+\).*/\1/p') | Postgres port: $(ps -ef | grep '[p]ostgres .*\/postgres\b' | sed -n 's/.* -p \([0-9]\+\).*/\1/p')"
Example output:
YCM port: 5433 | Postgres port: 6433
🤔 Why does it change by port?
When YSQL Connection Manager is enabled, YugabyteDB exposes two YSQL entry points:
Both connections can succeed, but only one goes through YCM.
🔢 YSQL ports, clearly explained
What is ysql_port?
ysql_port is the TCP port on which the YSQL (PostgreSQL-compatible) API listens for client connections.
- ● Default (no YCM):
5433 - ● Clients connect directly to PostgreSQL.
How can it be configured?
●
yugabyted:--ysql_port=<port>● YB-TServer:
--pgsql_proxy_bind_address=0.0.0.0:<port>● YugabyteDB Anywhere (YBA): via YSQL communication settings (for example,
ysqlServerRpcPort)
🔌 What changes when YCM is enabled
With YSQL Connection Manager (Odyssey) enabled:
● By default, YCM takes over port
5433for client connections● The PostgreSQL backend is assigned a random free port unless explicitly set
That’s why you might see PostgreSQL listening on 6433, 6543, or something else entirely.
Explicit configuration (recommended)
Set both ports intentionally:
💡 Port configuration callout (important!)
These port numbers are defaults, not requirements.
You can set the YCM port and the PostgreSQL backend port to any values you want; they just must be different.
YSQL Connection Manager (Odyssey) and PostgreSQL are separate processes, and they cannot bind to the same TCP port.
🧭 Final takeaway
● Connection success ≠ connection pooling
● YCM (Odyssey) and PostgreSQL are separate processes
● Defaults are conventions, not rules
● Always verify with:
SHOW yb_is_client_ysqlconnmgr;
- ● And when in doubt, confirm the actual ports in use with the one-liner above
Have Fun!
