The solidDB^® database server uses a client/server model; the solidDB^® deployment consists of cooperating server and client processes. The server process manages the database files, accepts connections to the database from client applications, and carries out actions on the database as requested by the clients.

The client process is used to pass the required tasks (through the server process) to the database. There can be several client types: a client can be a command-line tool, a graphical application, or a database maintenance tool. Typically, different applications act as clients to connect to solidDB^®.

The client and the server can be on different hosts (nodes), in which case they communicate over a network. solidDB^® provides simultaneous support for multiple network protocols and connection types. Both the database server and the client applications can be simultaneously connected to multiple sites using multiple different network protocols.

solidDB^® can also run within the application process. This is provided by solidDB^® shared memory access (SMA) and linked library access (LLA). In this case, the application is linked to a function library that is provided with the product. The linked application communicates with the server by using direct function calls, thus skipping the overhead that is required when the client and server communicate through network protocols such as the TCP/IP. By replacing the network connection with local function calls, performance is improved significantly.

To submit a query (an SQL statement) to a database server, a client must be able to communicate with that database server. solidDB^®, like many other database servers, uses drivers to enable this communication. Client applications call functions in the driver, and the driver then handles the communications and other details with the server. For example, you might write a C program that calls functions in the (ODBC) driver, or you might write a Java program that calls functions in the (JDBC) driver.