What is a database port?
A database port is the network endpoint number on which a database listener accepts client connections. The pair of host and port directs traffic to a process; the database protocol, TLS negotiation, credentials, permissions, and selected database determine whether a complete session succeeds. A port number is configurable, so a familiar value suggests a service but never proves its identity.
The practical task is not merely to ask “which port does this database use?” It is to identify the endpoint assigned to this environment, prove that the application can reach it, verify that the expected database protocol answers, and limit who can connect. That sequence covers both informational and troubleshooting intent behind database port searches.
Database port numbers: useful defaults, not guarantees
Default database port numbers help a client begin configuration and help an operator recognize likely traffic. They are not authoritative for a specific deployment. Containers, proxies, port forwarding, named instances, connection poolers, managed services, and security policy can all change the externally visible port.
| Database or service | Common default | What to verify |
|---|---|---|
| PostgreSQL | 5432/TCP | Server port, proxy/pooler endpoint, and managed-service connection details. |
| MySQL classic protocol | 3306/TCP | SHOW VARIABLES LIKE 'port'; do not confuse it with X Protocol on 33060. |
| SQL Server default instance | 1433/TCP | Named instances may use dynamic or custom ports; confirm Configuration Manager and connection details. |
| Oracle Net Listener | 1521/TCP | Listener address, service name, TCPS policy, and the installed configuration. |
| MongoDB | 27017/TCP | Replica-set members, SRV discovery, load balancer, and firewall policy. |
| Snowflake / Databricks | Service-specific HTTPS endpoints | Use the account or workspace connection data; do not force a traditional database default. |
Is a non-default database port more secure?
Changing a default port can reduce unsophisticated background scanning and log noise, but it is not an access-control boundary. Attackers can enumerate open ports. Real protection comes from private routing, narrow allowlists, verified TLS, strong authentication, least privilege, rate controls, and monitoring. Treat a custom port as operational configuration—not as a substitute for security.
How to find the database port your environment uses
Use the closest authoritative source to the listener. A copied wiki entry or default-port list is weaker evidence than current server configuration or a provider-generated connection value.
How to find a database port in a managed service
- Open connection detailsFind the provider's Connect, Endpoint, Networking, or Connection Info panel. Record the environment, database type, host, port, TLS requirement, and whether the endpoint is public, private, proxy, writer, or reader.
- Select the application endpointA console may show direct, pooled, read-replica, and private endpoints with different ports. Choose the one intended for the workload, not merely the first visible value.
- Confirm the network sourceA private port may be correct yet unreachable from a laptop. Test from the application subnet, runner, container, or approved jump path.
How to find a database port on a self-managed server
Inspect the database's active server or listener configuration, then confirm the operating system is listening on the expected interface. PostgreSQL exposes a port setting; MySQL exposes the port system variable; SQL Server Configuration Manager shows static or dynamic TCP ports; Oracle Net Listener configuration identifies protocol addresses. If a reverse proxy, pooler, SSH tunnel, container mapping, or load balancer sits in front, document both the client-facing and backend ports.
How to test a database port from the right network
A useful database port test uses the exact host, port, source network, IP family, and route that the application uses. Testing from an administrator laptop can produce a false pass or false failure when VPNs, private DNS, egress rules, service meshes, proxies, or security groups differ.
What does an open database port prove?
| Evidence | It proves | It does not prove |
|---|---|---|
| DNS resolves | The client received an address. | The route or listener works. |
| TCP connect succeeds | The path reached a process accepting TCP on that endpoint. | It is the intended database, or that TLS and login work. |
| TLS handshake succeeds | Transport settings and certificate trust are compatible. | The identity has database access. |
| Authentication succeeds | The server accepted the identity. | Required schemas, writes, or performance are available. |
| Health query succeeds | A basic end-to-end database session worked. | Capacity, failover, or sustained reliability is proven. |
How to check a database port without exposing credentials
Start with a TCP-only probe when the question is reachability. It needs only an authorized host and port. When authentication is necessary, use an approved, temporary, or least-privilege account and prevent the command, URL, output, shell history, logs, screenshots, and ticket attachments from capturing the secret. Never paste a production connection string into an untrusted checker.
Check an authorized database host and port
Prepare the exact host, actual listener port, database type, and approved source path, then open the InfiniSynapse DB Compatibility Checker. PostgreSQL, MySQL, MariaDB, Redshift, and CockroachDB support a one-time authentication test. Snowflake, ClickHouse, Databricks, SQL Server, Oracle, and MongoDB are tested for TCP reachability only.
Open DB Compatibility Checker A TCP pass does not validate TLS, login, permissions, database selection, queries, or production reliability.Diagnose database port refused, timeout, and unreachable errors
Why is the database port connection refused?
A refusal commonly means the target address responded but no process accepted the requested port, or a firewall actively rejected it. Check whether the database listener is running, bound to the intended interface, using the expected port, and permitted by the host firewall. Also verify that DNS did not resolve to a stale or wrong server. A fast refusal is different from a silent timeout.
Why does the database port test time out?
A timeout means the connection did not complete before the deadline. Likely causes include a missing route, security-group or ACL drop, blocked egress, private endpoint reached from a public network, IP-family mismatch, network appliance, or an overloaded endpoint. Compare the affected source with a known-good source, record DNS answers and route context, and avoid fixing a network failure by merely increasing the application timeout.
Why is the port open but database login still fails?
The listener may require a different protocol, TLS mode, server name, database/service selector, authentication mechanism, or credential. SQL Server named instances, Oracle service names, PostgreSQL database names, MongoDB authentication databases, and MySQL TLS modes are not interchangeable concepts. Capture the exact database error code after TCP succeeds; it usually provides better evidence than repeating port tests.
Secure database port access without breaking operations
- Prefer private endpoints: keep database listeners on private subnets, private links, VPNs, or controlled proxy paths whenever the architecture allows.
- Allowlist the smallest source: authorize an application security group, workload identity, or narrow source range on the actual port—not an entire corporate network by default.
- Verify encryption: require the database's supported TLS mode and validate server identity; encryption without certificate verification leaves avoidable trust risk.
- Separate monitoring from administration: port checks and health probes do not need owner, write, schema-change, or user-management permissions.
- Log decisions, not secrets: record source, destination, port, result, latency, error class, and timestamp while redacting usernames, passwords, tokens, and full connection strings.
Should you open a database port in the firewall?
Open only the exact destination port and only from the sources that require it. Confirm return traffic, egress policy, network ACLs, security groups, host firewall, proxy rules, and change window. Test before and after the rule change, then remove temporary access. Do not publish a database port to the internet simply because a local client cannot reach a private endpoint.
A repeatable database port validation workflow
- Define the intended endpointRecord environment, database product, client network, host, port, proxy or pooler, IP family, TLS expectation, and the owner of the decision.
- Verify configurationCompare provider details, listener configuration, server state, connection URL, and deployment configuration. Resolve conflicts before changing a firewall.
- Test layers in orderCheck DNS, route, TCP, TLS, authentication, database selection, and a harmless query. Stop at the first failed layer and collect its evidence.
- Compare sourcesRun the same test from the application workload and a known-good source. Differences reveal source-specific routing, policy, DNS, or identity problems.
- Close the loopDocument the actual port, approved source, test type, limits of the evidence, owner, expiry for temporary access, and monitoring signal.
Database port FAQ
What is a database port?
It is the TCP or, less commonly, UDP endpoint number where a database listener accepts network connections. The actual port is configuration, not proof of a product.
What are the most common database port numbers?
Common defaults include PostgreSQL 5432, MySQL 3306, SQL Server default instance 1433, and Oracle Net Listener 1521. Always verify the deployed value.
How do I find the database port?
Check provider connection details, active server/listener configuration, the connection URL or data source, and a known-good client. Prefer current server evidence over a default list.
How do I test whether a database port is open?
Run a TCP connection test from the application's network using the authorized host and actual port. Treat success as reachability evidence only.
Does an open database port mean the database is working?
No. It does not prove protocol compatibility, TLS, credentials, permissions, database selection, queries, capacity, or reliability.
Should a database port be exposed to the public internet?
Usually no. Prefer private networking, narrow allowlists, verified TLS, least privilege, monitoring, and a controlled access path.