Abstract: A method is described for on-demand creation of a database service. In response to receiving indication that the database service is to be created, an automated process is initiated, including instantiating a quantity of database servers. The database servers include a first subset of at least one of the database servers designated to handle read queries only, and a second subset of at least one of the database servers designated to handle write queries. The process includes determining a quantity and size of load-balancing proxies to instantiate for supporting the database server instance, and instantiating the determined quantity of load-balancing proxies of the determined size. At least one of the load-balancing proxies is a proxy configured to receive database queries and perform query routing among the first subset and the second subset, where one criterion for the query routing is whether a given query is a read or write query.

Abstract: Roughly described, a database query router is installed transparently in a network between database client systems and a database server cluster. One subset of the servers is designated to handle read queries only and a second subset is designated to handle write queries. The query router receives, through a network port, the database queries made by a client system, and directed to the IP address and port assigned to the query router. The query router determines whether the query is a read or a write query, and forwards read queries to servers in the first subset and write queries to servers in the second subset of servers. By installing the query router transparently in the network, no modifications are required to the software in either the client systems or the database servers in order to add query routing functionality to a client/server database environment.

Abstract: Roughly described, a database accelerator is installed transparently in a network between database client and server systems. It maintains a pool of connections to the database server(s) for re-use as needed. Connection requests from client systems are received and completed by the accelerator, and queries received on such client-side connections are forwarded through pool connections toward the database servers. If no appropriate connections are available when needed for a particular query, the accelerator forms one by emulating a client system requesting a connection to the desired database server. If the maximum number of connections has already been reached, then the query is queued until a connection becomes available in the pool. By installing the accelerator transparently in the network, no modifications are required to the software in either the client systems or the database servers to add connection pooling functionality to an existing client/server database environment.

Abstract: Roughly described, a database accelerator is installed in a network between database client and server systems. Connection requests from a client system are received and authenticated by the accelerator itself, which is pre-configured with user authentication information, by emulating the authentication process on behalf of the server. An authenticated connection from the accelerator to a database server is established only if and when needed. Involving the server for authentication can be avoided for example if the accelerator maintains a pool of such authenticated server connections for re-use as needed, and/or if the accelerator maintains a cache of query responses previously received and can respond to new queries from the cache. By installing the accelerator transparently in the network, no modification of software in either the client application or the database servers is required in order to add authentication offload functionality to an existing client/server database arrangement.

Abstract: Roughly described, a database accelerator is installed in a network having client systems which makes database queries to a particular IP address and port, and database servers which accept queries received at an IP address and port. The accelerator includes a cache, and is arranged to receive, through a network port, a database query made by a client system and directed to the particular IP address and port, return response data from the cache if available there, and if not, then forward the query through a network port to the database servers. Upon receipt of response data from the servers, the accelerator can retain it in its cache in addition to forwarding it back to the client. By installing the accelerator transparently in the network, no changes are required to either the client or server software in order to add query caching functionality to an existing client/server database arrangement.

Abstract: Roughly described, a database accelerator is installed transparently in a network between database client and server systems. It maintains a pool of connections to the database server(s) for re-use as needed. Connection requests from client systems are received and completed by the accelerator, and queries received on such client-side connections are forwarded through pool connections toward the database servers. If no appropriate connections are available when needed for a particular query, the accelerator forms one by emulating a client system requesting a connection to the desired database server. If the maximum number of connections has already been reached, then the query is queued until a connection becomes available in the pool. By installing the accelerator transparently in the network, no modifications are required to the software in either the client systems or the database servers to add connection pooling functionality to an existing client/server database environment.