I am trying to assess the feasibility of running Phabricator software on a shared host. I come with no experience of the software. I have, however, investigated the topic, and I acknowledge that the documentation discourages such deployments. A shared hosting solution is the only kind available to me, though, at this time, and I so wish to understand the particular obstacles and how to overcome them. I note that shared hosting services generally offer a LAMP stack, on which Phabricator is built, and as such services generally also supply a variety of tools intended specifically to work around the potential problems with sharing a host, most applications based on a LAMP stack will run on a shared host.
Currently, I am hampered by the curious design choice to use more than one database for the application suite, and moreover, to use a large number, the value of which is not predetermined or fixed.
I am considering the following statements from the documentation (emphasis added).
Phabricator uses about 60 databases (and we may have added more by the time you read this document). This sometimes comes as a surprise, since you might assume it would only use one database.
A cost of this approach is that it makes Phabricator more difficult to install on shared hosts which require a lot of work to create or authorize access to each database. However, Phabricator does a lot of advanced or complex things which are difficult to configure or manage on shared hosts, and we don’t recommend installing it on a shared host. The install documentation explicitly discourages installing on shared hosts.
Such explanation appears to be in direct conflict with the below appraisal, also taken from the documentation.
In almost all cases, creating more databases has zero cost, just like organizing source code into directories has zero cost. Even if we didn’t derive enormous benefits from this approach at scale, there is little reason not to organize storage like this.
Lack of support for shared hosts, as already acknowledged, plainly is a cost. In this case, the cost is greater than zero.
I would also suggest that the design of utilizing an unbounded number of databases for a single application suite has numerous further costs. A few of them are the following:
- Cluttering top-level namespace of a database cluster.
- Possibility of namespace collisions with databases used by other applications or application suites.
- Administrative overhead of separately provisioning permissions and other attributes of an undefined number of databases, rather than of one.
- Impracticability of protecting unrelated databases on the cluster from malfunctions in the application.
- Difficulty of cleaning a system of the databases used by the application, without relying on a functional installation of the application to automate the cleanup process, compared to simply removing the single database manually. Having the ability to effect such cleaning is particularly necessary in cases where a functional installation no longer exists.
- Violation of firmly established design principles, on which database management systems like MySQL are based. As such, the DBMS and other components may make assumptions following this principle, creating conflicts with any application that violates it. Such conflicts may occur even if their possibility is not apparent at the time the design choice is made.
However, more than wanting to rant on my own response to this design choice, I would really like to know whether any workaround is available that makes it possible to use the software on a shared host that does not permit applications to add databases.
Is any configuration mode available in which all the applications in the Phabricator suite create tables in a pre-existing database?