One way to better scale database interaction is to set up slave DB servers which are used for querying the data. The master DB server is only used for inserting new data and replicating it to the slaves. Architecturally this is a lot easier than a truly replicated database setup (with multiple masters that can be used for both reading and writing), and several such solutions exist (see for example Slony for postgresql). fergal's point still applies though, not all applications can benefit from this kind of setup.
So if you want to leave this option open for the future while building your webapp you should use different handles for reading and writing to the DB. Those can point to the same server during first deployment and later be changed to access the master and slave(s) when you need to scale.
