I always wondered, why a port must be assigned in order to use a DBMS? And what difference does it make using TCP or UDP (and even static and dynamic)?

Is it for communication purposes?

I know this is very basic question, but still I could not find a straight forward answer.


3 Answers 3


A port number is not necessary to use DBMS.

Individual programs could write directly to the DBMS's files. But the rules of a DBMS have become very complex, and an immense amount of logic is needed to respect those rules and to respect the actions of other programs using the DB. I've known that situation with Oracle, you could compile your programs to access the DB directly.

To avoid having even the most simple program becoming a huge blob, the DB authors came up with the DB server. A single program had access to the DB, others wanting to use the DB, had to "talk" with that program, which executed their requests and sent back the results. That single program has become a complete library, you can't count the processes of a single Oracle DB on your fingers and toes.

Now, "talking" between programs is inter-process communication. One possibility is a "socket", no port needed, on the unixes it is presented as a file to which the program can write a request, the server reads it, executes, and writes the result, which the program can read. Another possibility is TCP/IP, for which you need to know the port number. The program sends its requests to that port, on which the DB server is listening, etc. TCP is much more secure than UDP, slower, but no packets can get lost. You can't afford that with a DB. Another big advantage: programs running on other systems can use the DB.


In the SQL Server world, we have what was traditionally called "Network Library", which handles the communication between the client and the database server (nowadays this is often just referred to as "protocol"). We have had a bunch of network libraries over the decades:

  1. Named Pipes (possibly similar to a Unix socket, acts as a file from the programmers viewpoint, so to speak)
  2. RPC
  3. IPX/SPX (SPX is possibly the better term - anybody remember these?)
  4. Shared Memory (only work locally)
  5. VIA (something used in SAN, from what I understand)
  6. TCP/IP (TCP is the better term here)

Currently, SQL Server has 1, 4 and 6, the others have been removed from the product. What is transmitted between the client and SQL Server is packaged in a format called Tabular Data Stream (TDS). Hook up a network sniffer and catch one of those TCP packets and in there you will find a TDS packet.

Here's a blog post I wrote on the topic 12 years ago (still valid): http://sqlblog.karaszi.com/endpoints-netlibs-ipc-and-stuff/


A port is what allows any program to communicate over a network. Think of it like a television channel or radio frequency. Protocols like TCP and UDP are how programs communicate from port to port.

Certain ports are reserved/assigned for use by specific programs, like port 80 for basic HTTP web traffic, and port 443 for HTTPS for encrypted web traffic. There are many different protocols, each with a specific purpose or for a specific type of communication.

Databases most often use TCP as the base network protocol, because it includes a means of validation to ensure packets of data aren't lost in transit; it supports stateful communication, where UDP is more often used for stateless communication.

Additional application protocols are layered on top of TCP for specific programs. For example, Oracle uses a protocol named TNS on top of TCP to communicate with databases. Web browsers use HTTP and HTTPS on top of TCP. All of this is (other than assigning a port number for use) is generally transparent to users.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy