Any really cheap VPS deal is going to be very heavily oversold or the company is operating at a loss. If the arrangement is heavily oversold then you will experience performance issues at times, particularly with regard to I/O but also with CPU allocation. If such a business isn't heavily oversold then it will go out of business shortly unless the service is some sort of loss-leader to grab people's attention in which case support is unlikely to be top notch when they realise they are not going to make more money out of you.
So from that point of view I would avoid this plan without even considering the technical issues.
Running individual services on several VMs on the same host may turn out to be as fast as your current VPS (or at least "fast enough" for small loads, and perhaps faster for large loads if your design scales well over multiple machines) but it would be a lot more work to setup and would have some extra limitations. You could have the seven VMs you mention in an arrangement like this for example:
3 6
,---> web -------> db <----.
| server | slave |
| | |
1 2 | \ 5 /
firewall / ----> load ----| >---> db <--<
external access balancer | / master \
| | |
| 4 | 7 |
`---> web -------> db <----'
server slave
and properly setup you could expand quickly by adding more web servers or DB servers as needed. But there are a lot of issues to content with:
- You need to configure that load balancer well
- Each web server would need to be well tuned to work in 128Mbye of RAM or you'll be swapping so that IO hit from excessive contention due to heavy overselling is going to hit hard, and getting an Apache+PHP setup to work well in that little can be impossible anyway at the best of times depending on what you are running (check the potential per-process memory requirements for wordpress, for instance). You might be able to mitigate this by using a different web server (nginx for instance) and/or having the PHP instances running on yet more VMs called via FastCGI over the network, but this is yet more complication to setup efficiently and may still be impossible depending what your scripts do.
- You are going to have to configure that database replication either using one master with read-only slaves (which will require changes to your apps) as in my diagram or master-master arrangements which can be far less efficient if transactional integrity is something you care about.
- Each DB server will be limited to 128Mb: this can be a pain for mySQL and will require some tweaking generally, and a big query on one server is not going to be able to "borrow" memory spare on another so that limit is fixed. If you are not very very careful the DB nodes may end up swapping in which case there is that nasty IO contention surprise again.
- Four 128Mbyte machines will not operate as one 512Mbyte one: for a start the OS and app overheads are pretty much fixed and will apply to each node individually and nodes will not be able to share their RAM pool so a large query on one DB server or large process on one web node will not be able to second RAM allocated to another, currently idle, node. Seven machines 128Mbyte machine are not overly likely to work as well as one 512Mb one for many load patterns.
Further to the "there must be a catch" front, that 128Mbyte of RAM may not be dedicated: it might be "64Mb burstable to 128Mb" for a VZ based host or "64Mb with 64Mb swap" for Xen based systems. Even if theca RAM is nominally dedicated to your VM some virtualisation solutions allow over-committed RAM (VMWare does to a certain extent) so you find parts or your "dedicated RAM" paged out to the hosts swap areas which would be a massive performance hit. Another killer catch is that communication between the VMs (not just between them and the outside world) might count towards your bandwidth allocations: so pulling 512Kbyte from the database to one of the servers and after some computation sending a 128Kbyte response to the client might count as 1664Kbyte in total (512 out of db node, 512 into web node, 128 out of web node, 128 through load balancer, 128 through firewall) not just the 128K, and replication traffic between the DB nodes will count against your quotas in that instance too.
lt;dr: While this may be possible for some workloads (i.e. if each web/app/sql node in your design can run efficiently in that little RAM and you have enough nodes to cope with the same load) it is probably far far far far more hassle than it is worth, for light loads is going to run slower even on a good host (due to extra network overhead) and a really cheap host is unlikely to be a "good" host (an expensive host isn't guaranteed to be a good one, but it is slightly more likely!). Is all the extra setup and maintenance time involved really worth less than the monthly cash you would save?!
Their is one reason I might suggest doing this which is to learn: it could be an interesting project to learn the techniques, and gain first hand experience, of trying to scale apps over multiple machines for performance and/or availability reasons. I wouldn't recommend it for a production setup, even for a personal project, unless you already have that knowledge and experience (which as you are asking the question, I assume you do not).
Still lt; dr: I would stick with you single VM.
