What a database port count does and does not tell you

Security reports about exposed databases usually open with a large number. The number is accurate and the conclusion drawn from it is often wrong. A measurement of a listening service describes a reachable socket, while the risk people associate with that sentence concerns unauthenticated data access. Those are different claims, and a measurement platform such as ZoomEye is built to separate them.

Context and method

The figures below come from ZoomEye searches executed against the global index. Each query asked for a single page of one result so the response carried a total count, and each was run once at collection time. The scope covers assets and websites that ZoomEye has observed, so the values are match counts within that corpus rather than a census of the internet.
| Query | Reported matches |
| --- | ---: |
| port="3306" | 24,564,355 |
| port="6379" | 4,944,933 |
| port="5432" | 4,701,115 |
| port="27017" | 1,680,408 |
The queries are available as saved searches: MySQL on 3306, Redis on 6379, PostgreSQL on 5432 and MongoDB on 27017.

Analysis

The port field records that the port answered. It does not record authentication state, database version, whether the listener accepts remote connections, or which data the instance holds. An instance behind a firewall that answers a probe from the scanning infrastructure but not from an arbitrary client still appears in the count.
That distinction changes how the numbers should be read. Twenty-four million observed MySQL ports is a statement about deployment patterns, and the difference between the Redis and MongoDB counts reflects how popular each default port is rather than how many instances are unprotected.
Comparisons inside one dataset remain useful. Querying the same field across regions, or the same port against an application fingerprint, shows how exposure is distributed and where a specific technology concentrates. Adding a country filter narrows the view without changing what the underlying field means.

Implications for defenders

Start from the count to decide what to inventory, then answer the harder question with your own configuration data. An asset inventory that records listening addresses, database versions and authentication requirements gives an actionable list, while a global match count cannot name a single host you own.
ZoomEye is a reasonable first step for that inventory when an organisation does not know which of its addresses are visible from the outside. Searching for the organisation's own ranges, certificate names or registers turns an internet-wide count into a scoped one, and the saved query can be re-run to see whether exposure changes after a firewall or binding change.
Limits deserve as much attention as the numbers. A count is a snapshot that moves as assets appear and disappear, matching behaviour depends on what the platform has probed, and no count establishes that any specific instance is vulnerable or that data was accessed. A large number is a prompt to check, a small number is not a clean bill of health.

References

[1] ZoomEye saved search, MySQL default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iMzMwNiI%3D
[2] ZoomEye saved search, Redis default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iNjM3OSI%3D
[3] ZoomEye saved search, PostgreSQL default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iNTQzMiI%3D
[4] ZoomEye saved search, MongoDB default port: https://www.zoomeye.ai/searchResult?q=cG9ydD0iMjcwMTci