« NoSQL: If Only It Was That Easy | Main | Yahoo!'s PNUTS Database: Too Hot, Too Cold or Just Right? »

1dbase vs. many and cloud hosting vs. dedicated server(s)?

Me and my partner are making a blueprint for an online webshop service. The purpose of this project is to make webshops available for small company's/ individuals automatically just by creating an account with us. Our webapp can be used to add products/pages/... to the store and we'll handle secure checkout by paypal.

Our app should be scalable and manageable. Because we also want to offer free webshops, the amount of webshops could be +10.000 within a few years. We are building on the Zend framework and are using mysql for database.

From the start we want to build our application for optimal and easy scalability in the future, to avoid a lot changes to our app/database in the future.

Now our questions are:

Should we use?:
* one database for all shops (or limited to X shops );
* one database for each new shop (each having products, orders... tables);

I think both approaches have PRO/CONS. What do you think ? Does anyone has experience with this kind of structure ?

one database: easier to make changes to database layout
multiple databases:more scalable, easier to backup/restore

one database: harder to code because of extra keyfields in tables , slower or more difficult to backup/restore.
multiple databases: Takes longer to push changes to database layout

We are totally not clear on what hosting we should use. Would it be a solution to use a cloud service such as mosso/amazon/gogrid? Or is it better to just start with one dedicated server and expand 'manually' later?

Thanks in advance for your help!

Reader Comments (6)

A lot of issues. Stack Overflow seems to use a database per customer. Salesforce combines a certain number of customer per database and shares tables. If you can create the automated infrastructure to manage upgrades, setup, failover, etc then one per customer seems the most flexible and safer for the customer. Salesforce puts in an enormous amount effort to make their approach work, you probably want to put your efforts elsewhere.

If you are adept at datacenter and system administration then buying your own equipment will be cheaper. So if your margins or skills are thin then this might be the way to go. Otherwise the flexibility of the cloud is hard to beat.

Look at your skills. Your costs. Your revenues. Your growth. Have a realistic view of all these and that will move you into the right coordinate in the solution space.

November 29, 1990 | Unregistered CommenterTodd Hoff

Thanks for your reply Todd! Currently we are moving towards 1 database per customer, like you said.

Can you elaborate why cloud flexibility would be so great for us? I mean, image that one dedicated server cannot handle the load anymore and we would need one extra server for database calls only, or maybe even 2 where one would be the read database, the other the write database. Just thinking out loud here...

Is that something that would be handled by a cloud hosting like gogrid automatically? I mean, does it scale just like that? It's not really clear to us what exactly is being scaled. Or are there things that cloud hosting just can't handle?

Thanks again for your help.


November 29, 1990 | Unregistered Commenterjorre

Nothing scales like that :-) You have to architect your system to work in a cloud. A cloud is convenient because you can quickly spin up a copy of your site for development and testing. That's hard to do when all the hardware is hard coded. Using cloud storage is convenient for snap shotting backups, storing and serving images, that sort of thing. And if you are white labeling store fronts provisioning more nodes is quite simple, especially if you expect a lot of customers.

November 29, 1990 | Unregistered CommenterTodd Hoff

I don't really understand how it will help us when we'll have a lot of customers. Does it scale infinitely just by adding more server instances to it? How about disk I/O or database access with a lot of customers. Does that scale as well?

Or is a cloud just a little piece we should use to store our users images for example, in combination with our own server(s)?

November 29, 1990 | Unregistered Commenterjorre

Although the goal of a cloud is to seamlessly add resources automatically to deal with your traffic, only billing you for the resources you use, we are definitely not there today... Today, clouds like amazon, gogrid and mosso cloud servers that you mentioned simply provide virtual servers at an hourly fee. So if you need more servers for a short time to handle traffic, just buy them on the spot. You get the servers immediately and you only pay for the time you use them. Same goes for cloud storage.

You also mentioned deciding between dedicated servers and cloud hosting. You don't have to decide... newservers.com provides dedicated servers in the cloud. The above services give you virtual servers on-demand at an hourly rate. newservers.com gives you physical dedicated servers on-demand at an hourly rate.

November 29, 1990 | Unregistered CommenterAnonymous

Thanks a lot for your help. Can you clear this up for us:

we would e.g. start with one server instance or virtual private server.
Our application and mysql will run on the same server.

What should we do if we notice that this one server can't handle all traffic or database load anymore? Or is this not an issue on a cloud, does it scale when our traffic or load increases?

Or do we have to deploy another server instance in the cloud and then what? Configure/rewrite our application so that it works with 2 servers? Or maybe let one instance act as mysql-server and the other as a webserver to split the load?

Once we add another server instance and decide that our mysql will run on that new instance, we cannot simply shut it down when load decreases again, so it will cost us money continuously, just like when renting a second virtual private server?

Or how should we see this? Please advice!

November 29, 1990 | Unregistered CommenterAnonymous

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>