<p>I am working on a PHP application that intends to ease company workflow and project management, let's say something like <a href="http://www.basecamphq.com/" rel="noreferrer">Basecamp</a> and <a href="http://goplan.org" rel="noreferrer">GoPlan</a>.</p>

<p>I am not sure on what the best approach is, database-wise. Should I use a single database and add client-specific columns to each of the tables, or should I create a database for each new client? An important factor is automation: I want it to be dead simple to create a new client (and perhaps opening the possibility to signing up for yourself).</p>

<p>Possible cons I can think of using one database:</p>

<ul>
<li>Lack of extensibility</li>
<li>Security problems (although bugs <em>shouldn't be there in the first place</em>)</li>
</ul>

<p>What are your thoughts on this? Do you have any ideas what solution the above companies are most likely to have chosen? </p>

For multitenancy, performance will typically increase the more resources you manage to share across tenants, see
http://en.wikipedia.org/wiki/Multitenancy
So if you can, go with the single database. I agree that security problems would only occur due to bugs, as you can implement all access control in the application. In some databases, you can still use the database access control by careful use of views (so that each authenticated user gets a different view).
There are ways to provide extensibility also. For example, you could create a single table with extension attributes (keyed by tenant, base record, and extension attribute id). Or you can create per-tenant extension tables, so that each tenant has his own extension schema.