Database is the heart of almost any real world software system, and when it comes to choosing the right platform to host your database, two of the famous names are AWS RDS and Heroku PostgreSQL.
In this tutorial I briefly compare the key factors of each of these two offerings without going too deep in the technical details, while hopefully keeping it clear enough to be able to draw a conclusion based on these facts. Also I do not include Redis in the comparison as like many of you even I'm not yet convinced that Redis is a database, plus it's totally a separate service in AWS which I'll cover in another post.
To begin with, let's take a look at the different Database offerings the two platforms provide.
Supported engines
| Database | AWS | Heroku |
| PostgreSQL | Yes | Yes |
| MySQL | Yes | No |
| MS Sql Server | Yes | No |
| Aurora | Yes | No |
| Oracle | Yes | No |
Winner -> AWS
Considering the fact that Heroku doesn't even support many different database engines, let's just compare the same database engine that is provided by both platforms, yup our lovely elephant DB, PostgreSQL!
Again, let's simplify the comparison and start with few side by side comparisons demonstrated in tables.
Versions
| Version | AWS | Heroku |
| 9.6 | Yes (deprecated) | Yes (deprecated) |
| 10 | Yes | Yes (deprecated) |
| 10 | Yes | Yes |
| 11 | Yes | Yes |
| 12 | Yes | Yes |
| 13 | Yes | Yes |
| 14 | Yes | No |
Winner -> AWS
##Failover
| Feature | AWS | Heroku |
| Url Change | No (good -> seamless) | Yes (bad -> restarts applications) |
| Supported plans | All | Only Premium, Private and Shield tier plans |
| Read only support* | Yes (if more than two AZs selected) | Yes (with extra setup) |
*Url change refers to the fact that the URL/endpoint of the database does or does not change after the failover.
**Read only support is about whether the failover/follower instances can be used as read-only databases or not.
Winner -> AWS
##Backup Although you might think you won't need backup and restore functionality that often, you can find yourself restoring production databases in development environments many times. Also, RPO, RTO and in general your disaster recovery strategies are directly impacted by the effectiveness and simplicity of the backup/restore functionalities available to you.
| Feature | AWS | Heroku |
| Point in time recovery | Yes (by default) | Yes (conditionally) |
| Supported plans | All | Only Standard, Premium, Private databases tier plans |
| Rollback history | 7-35 days (no limitations) | 4-7 days (depending on your plan) |
Winner -> AWS
Pricing
This one can be a bit misleading. Here we're comparing only the price of the service exclusive of the labour and/or the set up and maintenance price. Also the list is not an exhaustive one but it's a good indicator of the actual difference between the two platforms.
| Memory size | AWS | Heroku |
| 4GB | $53.19 - $59.6 (w/w.o multi-AZ storage) | $50 - $350 (based on features) |
| 8GB | $118.5 - $144.1 (w/w.o multi-AZ storage) | $200 - $750 (based on features) |
| 16GB* | $277 - $288.2(w/w.o multi-AZ storage) | $400 - $1200 (based on features) |
*AWS 16 GB memory was the closest match to Heroku 15 GB memory
It's worth mentioning that all the pricing difference in AWS column is based on the extra pricing for the storage when Multi-AZ option is available, otherwise irrespective of the price and size RDS instances have all the features.
Winner -> AWS
Simplicity of use and operational overhead
This section is more of an analytical experience instead of quantitative comparison.
Provisioning a database Heroku gives you way less options meaning way fewer decisions to be made, and faster progress knowing that lots of the decision Heroku takes for you are already descent decisions. On the other hand, AWS gives you heaps of options from deciding the VPC and subnets to setting the security groups, parameter groups and option groups. While this might sound appealing at first, we should consider that it comes at the price of increased complexity, meaning a lot more time to spend, and many more ways to take wrong decisions.
Backup and Restore Heroku has simple options to create backups and restore the databases but again doesn't give you much control even on how long you want to retain the backups. AWS on the contrary gives you plenty of options or decision points from a different perspective but again it requires a good understanding of how RDS works and even knowing the fact that your RDS snapshots are stored on S3 can help you better understand the logic behind some behaviours.
Monitoring Heroku provides very limited monitoring options out of the box which can be enough in many cases but as your use cases become complicated they definitely lack many metrics that can help you troubleshoot the system. AWS on the other hand gives you the ever growing CloudWatch metrics which can help you fine tune even the applications using that database based on the behaviour that becomes clear looking at the extensive metrics available to you. As you can guess, again you have to navigate to different sides of the AWS dashboard to be able to get the metrics you want with the level of details you like, while still some metrics are available on the RDS page with limited options.
On top of all these differences, setting up read-replica instances, failoever and many optimisations on RDS are way more involved than the Heroku's counterparts, meaning that you have to shift the focus from building the product and providing a better service towards operational activities.
Winner -> Heroku
Choosing AWS as your platform while might look like buying directly from the factory, comes at the cost of lots of DIYs which can heavily impact where you spend your time, i.e. product vs operations, and can even impact your hires.
It's very typical for the teams that run their solution on AWS to have multiple DevOps engineers for the larger teams or hire developers particularly with AWS experience to handle the operations for them while doing their coding tasks in smaller teams. Obviously the DevOps engineers, permanent or on contract, in most cases are way more costly than the savings you were planning to have if that was the reason you choose AWS over Heroku and asking the developers to manage AWS means lots of distraction, sub-optimal infrastructure utilization, and in most cases less skilled developers (you're hiring someone who knows AWS and deep down you know that you're willing to sacrifice the development skills to some extent).
Overall if in the middle of the article you were completely convinced that picking AWS is a no brainer, I believe you might now factor in more real life parameters in your assessment.
The best of both worlds
Simplicity of Heroku, means less operational cost and more agility in the development of the product, with a developer first experience and more focus on shipping a quality product that directly brings value and generates revenue.
The high quality service that AWS provides has a way lower cost for the raw material (yup I'm calling RDS raw material compared to Heroku, please forget the pre-historic datacenter era!), along with perfect integrations with the rest of your platform and advanced options to make the solution way more secure irrespective of the instance size.
Utopiops is a solution that gives you the simplicity that Heroku provides on AWS meaning you can now have the best of both worlds. Not only that, as the solution is provided on your own AWS account lots of advanced configurations are included without your involvement. You get your extremely popular RDS with a set up that most experienced DevOps engineers and solution architects can provide with such a simplicity that any developer can use it.
What does it mean for DevSecOps engineers?
While Utopiops is starting a new era that we call no-ops and low-ops, it doesn't mean the DevOps role will become redundant at least in the near future.
The operational expenses of the companies will definitely reduce in the future benefiting from platforms and services like Utopiops, while helping teams to achieve even more.
Auto-tuning the parameters, settings, scales and even diagnosis are a few of the things you can expect to see in this era, meaning that the DevOps role will shift more and more towards solution architect activities and the experts in the field can help the teams achieve more by designing more complex and efficient solutions without having to go through the unnecessary, boring and low level grunt work.