title: Backend: remote vs local sql database
body: <p>What is your position on having the (relational) database on the same machine as the application server if you want to have a scaleable backend which can handle around 200 simultaneous requests?</p>
  
  <p>I see most are discouraging this approach with the following main arguments:</p>
  
  <ul>
  <li>Scaleability is more tricky</li>
  <li>Security (as both AppServer and DB on same environment)</li>
  <li>Resource competition of DB and AppServer</li>
  <li>Single point of failure</li>
  </ul>
  
  <p>However, I still see alot of advantages by going with the approach to have both on the same server, being:</p>
  
  <ul>
  <li>Costs: in particular, egress costs: having a seperate server for my db will result in almost twice the outbound transfer costs (once from db to the appserver, and once from appserver back to the client). At least that's the case for almost all providers, who charge for your server's outbound traffic. An issue I would not face if the db was simply on the same server. Of course you can decrease it by efficiently making use of your appserver's cache, but the main issue still remains.</li>
  <li>Speed: eventhough you'd still access the local db via TCP, localhost will simply be faster</li>
  <li>Scaleability: where is the issue really, I could just run the DB in an own VM and scale by upgrading hardware and assigning the hardware to the VM which needs it. Or scale horizontally with a new VM/K8s/whatever instance, even if both my AppServers and my DB are on the same machine</li>
  <li>Same resources: again, by having both in their own VM, I could just assign the hardware resources whereever they are needed - no competition at all?</li>
  </ul>
  
  <p>From what I see it, the question to put the db on a remote server might simplifies things and improves your security, but I also see alot of advantages with the other approach such as costs on outbound transfer. So is it safe to say that it's very situational and based on your actual project needs?</p>
  
  <p>(I intentially do not mention all-in-one SOA architectures from Google, AWS, MS Azure, as their costs simply don't make them an option).</p>