Back to blog home page

Where Should I Store All of My Data?

Posted by on Feb 03, 2015

One of the common questions in web development is “Where do I store my data?” As few as five years ago, the answer to this question was most often simple: on a server in-house that your website can communicate with. However, with the advent of services like Amazon RDS and other off-site data hosting providers, the nature of this decision has changed. Below we will look at storing a database on-site versus using a web service to provide data management. We’ll examine the pros and cons of each approach, and provide some easy tools to determine which solution best fits your needs.

Consideration 1: Application Size and Age

The size and age of your application is one of the first considerations in choosing your database provider. If you are developing a relatively new, small application, then the cost of creating, configuring, and deploying a local database server may be a significant portion of the total application development. Using a ready-made provider like Amazon RDS can reduce or eliminate a lot of the start-up costs associated with deploying a physical database server. In essence, this removes the hardware cost from the equation entirely. Deploying a local database instance requires procurement of the machine, configuration of the server to properly secure the connection as well as install the relevant applications, and all performance enhancements have to be handled in-house. With an implementation on a platform like Amazon RDS, all of these hardware costs and concerns are handled externally, allowing your tech team to focus on developing the best application that they can.

However, as an application grows – and the amount of data it stores and accesses grows with it – this equation can change. Higher performance RDS instances, as well as increased storage space, result in higher costs. Additionally, the cost to port an existing database to a cloud service can be non-trivial, particularly if a complex environment has grown to surround the data store. Ultimately, a team managing an established application needs to determine whether or not the effort required for the transition is sufficiently outweighed by the overall savings in hardware and scalability.

Consideration 2: Scaling

Once a database instance has been established for a web application, the next problem to tackle is handling performance improvements. The key to this question lies in the type of application being managed. An internal application handling employee records, for example, may not grow particularly quickly, and may ultimately provide a relatively stable performance profile. However, if an application is poised for rapid growth in either data or concurrent usage, then the hardware dedicated to serving up the database instance must be able to grow to match the demand. For a local data warehouse, this means increasing the amount of hardware dedicated to the database, improving network connectivity and latency, and adding additional storage – all costly items that require not only hardware purchases, but manual effort for maintenance and implementation.

By using a cloud service to provide remote data storage, all of these issues are mitigated by the third-party contracted to provide hosting and access. Instead of purchasing, installing, and configuring new hardware – a process that could take weeks of effort – the performance of your assigned instance can be increased (or decreased) with a phone call, or even without any interaction other than additional settings on an administrative portal. Hosting costs obviously scale with performance, so while in the long run an external hosting provider may provide an easy way to increase size and responsiveness of your data store, the additional cost may outweigh the benefit.

Consideration 3: Security

Security is an important element of any web application. From SQL injection prevention for a simple data-driven app to information security for a healthcare website, security is a significant proportion of the application’s architecture. When it comes to implementing database security, there are a number of factors to be taken into consideration. The first factor is likely the most obvious: does your team have adequate expertise to secure your database against potential attackers? If your team is lacking in security experience, then being able to outsource the database portion of your application can shore up that weakness in your application’s infrastructure. The second factor is attack mitigation – many attacks are focused on availability rather than data access. An external provider – with a larger dedicated hardware allocation – can more easily handle Distributed Denial-of-Service (DDoS) attacks, where an internal server would likely not be able to hold up under load.

An external provider, however, cannot often provide specific security elements that may be required for a particular application. By handing the database to an external party, your organization relinquishes a significant amount of control over the underlying security infrastructure. In some market verticals – anything involving customer financial information, for example – this can create challenges when meeting the requirements set by various regulatory bodies.


There are a number of considerations that come into play when selecting a method of data storage. While the above three items are certainly important, they are by no means the only elements driving the selection of a database provider. The important takeaway from this discussion is that each situation is unique. Some elements of a database implementation will likely always be improved by the use of a third-party data warehouse provider, such as performance and storage scalability, but the loss of control inherent in choosing a third party may offset any potential gains in implementation costs.

Build your Angular app and connect it to any database with Backand today. – Get started now.