5432 and 1433: two database ports, ten million answers, and the question of what answered

The counts

Database ports appear at very large scale in internet-wide scans. ZoomEye queries run on 26 September 2026 returned 4,685,422 results for port="5432", the conventional PostgreSQL port, and 5,877,157 for port="1433", the conventional Microsoft SQL Server port.

Together the two figures exceed ten million. Taken literally they would suggest that more than ten million database services are exposed to the internet. That reading is wrong for reasons that are more about measurement than about databases.

Context and method

The queries were run on 26 September 2026 between 04:33 and 04:36 Beijing time, which is 2026-09-25T20:33 to 20:36 UTC:

• port="5432"
• port="1433"

A port-level match reports that a host accepted a connection on that TCP port during the scan. It says nothing about what the peer was, whether a protocol exchange completed, whether the listener required credentials or whether the host was a database at all. Ports 5432 and 1433 are conventional choices and not reserved ones, and nothing prevents an unrelated service or a proxy from binding either. Scan indexes also change over time, so a count describes a moment in the crawl rather than an inventory you can rely on next month.

Why the numbers are inflated

The most likely source of inflation is that a listening socket can be a forwarder. A load balancer, a container network, a cloud provider's managed endpoint or a security appliance can accept a connection on 5432 or 1433 and pass it along, or terminate it. Each of those appears as one answer in a port scan without being a database. Address translation produces a similar effect: many internal hosts can sit behind a single published address, so one answer can represent a service that fronts a whole fleet.

There is a second, quieter source. Cloud and hosting ranges account for a large share of any large port count, and those ranges routinely include hosts that answer on a port as part of a shared network appliance or a managed platform edge.

The practical conclusion is directional. These ports receive a very large amount of inbound connection traffic on the public internet. That is a durable and useful observation, and it does not require the number itself to be a database census.

Why database exposure remains the point

Databases hold the data that the rest of an application exists to serve, and their authentication models were designed for trusted networks. A database reachable from the internet is reached by credential-guessing traffic continuously, and the controls that matter are network-level: a private subnet, a security group rule and an encrypted path through a bastion.

There is a related pattern worth watching. A database that is meant to be internal can become reachable when a developer adds a temporary rule, a managed service is provisioned with a public endpoint, or a container platform publishes a port by default. Those changes are easy to make and easy to forget.

Next steps with ZoomEye

• Run port="5432" and port="1433" for the network ranges you own, and treat the result as a list of addresses to verify internally rather than a list of databases.
• Combine the port query with a product fingerprint where one is available, so that confirmed database banners can be separated from bare port answers.
• Repeat the query monthly. A stable count in a range you control is a sign that no new public endpoint was created, and a jump is a signal to find out why.
• Verify your own databases from an external vantage point. An internal scan cannot show what the internet sees, and the difference between the two is often a rule someone added months ago.

ZoomEye provides the port-level and fingerprint-level views in one interface, and that combination is what makes the comparison practical. The counts describe inbound reachability, and the operator's own inventory is what decides whether any of it matters. The platform is documented at https://www.zoomeye.org/.

References

• ZoomEye search platform
• PostgreSQL documentation on authentication and connection security
• Microsoft documentation on SQL Server network configuration and security