My aim is to write a collection of many webapplications, like google services (mail, calendar, docs, ...).
It will be written in PHP with Zend Framework (Version 2). I use MySQL to store data.
The service collection should always be extendable (new services) easy.
Is it useful to provide a own database for every service? They would have few tables only (more or less 3). That would mean that I have to use Zend's multiple database adapter.
The other solution is to use one big database for the hole collection. The advantages are that I can use foreign keys between the tables of different applications. I also could use the default database adapter.
All the applications are enmashed with each other close.
What makes more sense?
Break the services out with one database each, including the service that identifies the users. All of the services should talk to each other via web services. This architecture will be the most flexible in terms of scaling pieces individually as well as maintaining the pieces individually.
It is impossible to give anything more specific in terms of architecture of such an application ecosystem without substantially more information about the project, and incidentally, that would be beyond the scope of this site to answer.
If you have enough databases from your provider you could use multiple databases, but if you have User accounts its better to create one main-Database for that.