Database connections and web site performance

I’m just finishing a web site for my client. It’s not a big website, and database is not big either, about 20 tables with each table has between 100 to 2000 rows but they will be growing. Now, my client also wants to build about 20 mini websites for its departments, and their prediction is with less tables and rows. They’re all will be in a VPS server using Centos, Apache, PHP 5.6 and PostgreSQL 5.6 with 8GB RAM. And their website was not a heavy-traffic type site (approx. 500 visitor a day)

My question is: what is best from a site performance point-of-view: to have those 20 mini websites with their own databases, or do I create their tables in one database?

Thank you.

Disclaimer: I am not a database expert

I wouldn’t have thought there’d be any noticeable difference in performance given the size and traffic. It’s more a call based on how you plan to manage the data (backups, will you ever need to move some tables to other servers). If you do put them all in one database I’d use a table prefixing system (site1_, site_2, etc) so you can easily differentiate them. It’ll also be easy to split them if you never needed to (e.g. for performance reasons).

1 Like

How similar will the mini sites be to this existing website? If much of functionality will be similar it would make sense to allow the new websites to run from the same database and code base. That way only a single code base and database needs to be maintained. However, if the existing project can’t be generalized to support the business requirements of the new projects than it makes sense to treat them as completely different code and databases. The ideal scenario would be running these new sites from a shared code and database.

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.