Database topologies
Consider the database configuration options in relation to your IBM® WebSphere® Portal deployment scenario. The complexity of the network topology will increase as you scale from a proof-of-concept environment using Derby to systems using vertical and horizontal clustering techniques.
WebSphere Portal data can be configured in a single store or organized into database domains to meet different availability requirements, depending on your deployment scenarios for proof-of-concept and production environments. The database domains provided by WebSphere Portal help you classify and distribute portal data. Each database domain can be placed on a separate database for efficient maintenance. Additionally, each domain can be placed on a separate database server system for maximum performance.

- Proof-of-concept deployment using a local database
- You can install the database server on the same server machine as WebSphere Portal. This is typically referred to as a local database. Using a local database can make administering your environment easier; however, this setup is best used for proof-of-concept deployments only, as a local database competes for server resources with your portal and provides a single point of failure for your entire portal environment.
- Normal load balancing using one or more remote databases
- You can install the database server on a different server machine from WebSphere Portal. This is typically referred to as a remote database. Using a remote database can provide performance benefits, depending on the speed of the network. When multiple lines of production are involved and each line of production is implemented as a cluster of servers, sharing database domains ensures that the data is automatically synchronized across the lines of production. Each database domain can be placed on a separate database for efficient maintenance.
- High-capacity load balancing using one or more remote databases
- When you deploy the portal in a large-scale, high-demand environment, you can dedicate a server specifically for database transactions. As more users access the portal, the portal application becomes database intensive. Database activity can take up CPU utilization and disk I/O time. Separating the database from the server that the portal is running on increases its capacity. Each domain can be placed on a separate database server system for maximum performance.