Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on
MySQL Database on same server Vs different server
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

MySQL Database on same server Vs different server

evnixevnix Member
edited February 2017 in General

What are your experiences with having database on same server Vs different server. I mean with respect to latency, setting it up, maintaining backups(which model is easier?).

Also I see a few hosts offering Database as a service.

[Member since 2012


  • For big production stuff always on different machines as then there is no CPU or memory contention under load. For smaller stuff I just put it all on the same box as it's cheaper.

  • WebProjectWebProject Member, Provider

    different server for mysql is normally much better performance, easier for maintenance and backup.

    VPS Price Match Guarantee on: All our range of DDOS protected XEN-HVM VPS Plans
    Are you looking for best price for self-managed VPS? See WebProVPS website for more details.
  • In terms of latency and easiness, having them on the same server generally wins. Backups may depend on how you do them, but I think it's largely the same regardless, for the majority of cases.

    Splitting up the two is mostly beneficial when:

    • One server cannot handle the load that your application + DB requires
    • With your way of managing servers / how the provider supplies them, it's easier to separate (e.g. different VM level backups for application and DB)
    • It may help with scaling to certain loads/requirements (e.g. if you want lots of CPU for your application, and lots of RAM for the DB, you may be able to get them better separately rather than trying to have both in the same box)
    • Resource contention between the application and DB is a concern (I'm assuming you're not imposing restrictions otherwise, eg via a VM)

    I'd generally go with the two on the same server unless there's specifically a reason not to. You can always split up the application/DB at a later point in time. Same server has a number of benefits:

    • Cheaper
    • One less server to manage
    • Resource sharing benefits, i.e. if your application uses lots of CPU but little RAM, and the DB is the other way around, sharing the same server can be an efficient way to use available resources. Also, there's no additional resources consumed by a second kernel.
    • One less failure point (the network)
    • Don't have to worry as much about failure modes where one server is down (e.g. how your application should respond if the DB server is dead / network is congested etc) - with one server, it's either all down or all up
    • Better performance: no network latency (plus ability to use Unix sockets for communication instead of running over a full TCP stack)
    • May be easier to keep consistent backups if your application holds any state outside of the DB (in other words, you don't have to worry about mismatched data when restoring from a backup if the two services have their own state)

    DBaaS is a bit different. I've personally felt that if you're comfortable with DBA, it's usually better to manage your own as you get much more flexibility. However, if being a DBA scares you, or you have relatively basic needs, it's probably better to outsource it. Obviously DBaaS is going to be easier than self setup. It also forces you to have a split DB/application setup as well.

    Thanked by 3rm_ k0nsl varwww
Sign In or Register to comment.