When it comes to hosting an application database there are thousands of options available, and despite what you have been told, there is no single right choice. The goal of this article is to discuss the differences in DB hosting in effort to help you decide what is right for your app.
Let’s start with the simplest and most proven form of hosting—dedicated. With dedicated hosting you are leasing a physical server in a datacenter for an agreed upon duration. As the name would suggest, your hardware is dedicated to you, meaning you don’t need to worry about someone else’s software or configuration impacting your environment. The advantage of dedicated hosting is generally the price. By agreeing to set lease length, hosting providers can offer very competitive rates on their hardware. Dedicated hosting providers also offer basic security, scaling and disaster recovery features. The disadvantage with dedicated hosting is everything is generally slower due to the lack of virtualization and automation. This form of hosting is best for cost conscious projects that can predict usage with a high level of accuracy.
Cloud hosting, a virtual machine, is very similar to dedicated hosting in that you are choosing a server specification, however the added “cloud” factor affords a level of automation that makes scaling significantly easier. Unlike dedicated hosting, scaling a VM can often be done with a few clicks and 5-10 minutes of downtime. Also, since the VM creation is fully automated, there tends to be no limit on the duration of leasing the server. If you need a server for a few hours or days, you simply pay for those hours you have the server up. Don’t think this flexibility comes cheap though. Normally a VM runs double or even triple the cost when compared to a dedicated server. Cloud hosting a VM should be considered if you are unsure the server specifications your app needs early on or if your application prioritizes scaling.
The aim of serverless hosting was to improve upon traditional cloud hosting. The best way to think of serverless is to remind yourself you are not leasing a server—you are leasing computation time. Instead of having a server, you purchase capacity on a shared server. By giving up dedicated hardware you are given a level of flexibility that makes scaling very simple—in some cases with no impact to end-users.
Serverless puts most of the management into the hands of the hosting provider. Things such as disaster recovery, monitoring and availability are considered services and free you up to focus on your application and not the hardware.
These features come at a price though. When compared to a virtual machine, serverless can cost up to twice as much. Serverless should be considered if scaling is a high priority or if you simply don’t want to worry about managing servers.
Serverless hosting can vary heavily between providers. As such there are some considerations you should keep in mind when determining which provider is best for your application:
Since serverless hosting removes the hardware the pricing can sometimes be difficult to understand. Often hosting providers create new terminology that can represent a homogony of CPU, Disk and Ram. This pricing model requires an entire document to explain and can be difficult to migrate from a traditional server. You may think “100 XYZ units” translates into a 2 core 8gb server but in fact it’s a fraction of that and your cost doubles.
Sometimes pricing seems simple but is difficult to visualize. When you see a price like $0.00125 per second per core it seems cheap until you realize there are 2.6 million seconds in a month and hosting 2 cores would run you over $6k a month. Don’t get me wrong, precision in pricing is a good thing, and if managed properly you can save money; just make sure whatever option you choose shows you estimated cost and is clear what you are going to pay at the end of the month. The last thing you want is a surprise bill.
If a hosting provider doesn’t make public their outages, don’t use them. Another thing to consider is how far back they go in reporting issues. For example, some hosting providers may only go back a week or two. This typically means they want you to have a short memory on outages. Ideally you want at least 2 months of availability metrics, including latency, to look back on. This should give you a decent picture on how their servers will perform in the long run. Remember, since you don’t have access to the hardware, you and your app are 100% reliant upon the hosting provider to keep things running smoothly.
This one is obvious, but it’s worth mentioning. If you are going the route of serverless you are most likely trying to save time in developing. This cost savings is negated if the SDK for integrating the serverless architecture is difficult to work with. Ideally whatever platform you choose would have little to no proprietary aspects. The best for serverless is one that offers a standard method of integration such as REST or direct DB integration.
If moving to the cloud is a priority, yet your application needs a level of control only available on an server, you may find a cloud hosted virtual machine is a great solution. An example of this might be additional software needing to be installed on the hosting server for your database to run properly such as a reporting server or background job scheduler. Virtual machines give you the ability to have custom configuration alongside scalability. Sometimes going serverless just isn't possible due to software limitations with your app, and spending time time to redesign your application just isn't worth it.
No matter how perfect your serverless hosting may seem at first sight, there will come a time when you need to consider moving away from it. It may be a result of investors wanting to weigh risk when purchasing your application, or it may be a result of your hosting provider raising costs on you. The last thing you need is to findout it takes a thousand hours to migrate away from your serverless hosting provider, leaving you feeling trapped. Ideally you want to be able to export your database into a known format and have a plan to host that database somewhere else.
The best serverless options offer features on top of just hosting your database. This may come in the form of better management tools such as logging or dashboard visualizations. It may also come in the form of simple integrations like an SDK or a RESTful interface to connect to your database. Whatever the case, you should be getting more value from your hosting provider than simply a database.
There is a ton more that can be said on database hosting; however, we hope this article reminds you that choosing the right solution is more about the core values and priorities of your application than any one best practice. Even though our personal bias leans towards serverless, we recognize that ease of integration or pricing may make a dedicated or vm solution the right choice. Make sure your project gets off on the right foot by choosing the right hosting early on!
If serverless sounds like it could work for you, we suggest checking out MeshyDB.