After EC2, our AWS cloud series moves on to data: Amazon RDS is the managed relational database that takes care of backups, failover, patching and monitoring for you. Let’s see what “managed” really means, how much flexibility remains with extensions such as pgvector and PostGIS, and when it beats a self-hosted database.
Amazon RDS: all the power of PostgreSQL, without the late nights
Article by Gaia Pistori – Full-stack Developer at AzzurroDigitale
In the last episode we talked about EC2, the building block on which much of the cloud rests. But once your instances are up and running, the next question comes straight away: where do I put the data? You could install PostgreSQL or MySQL, the two most popular databases, on an EC2 instance and manage them yourselves, with all the backups, safety copies and maintenance that come with it. Or you can leave the boring part to AWS. This is where Amazon RDS (Relational Database Service) comes in. In this episode we look at what really changes in day-to-day work, explaining technical terms as we go.
What “managed” really means
“Managed” is not just a brochure word. It means AWS takes on a big chunk of operational work, the kind that requires time and specific skills. Here is what it includes in practice:
- Automated backups: every day AWS creates a full backup of the database (a “snapshot”) and keeps it for up to 35 days. You can also restore to a precise point in time. Very handy if someone accidentally deletes data at 2:32 pm on a Tuesday, and no scripts are needed.
- Automatic failover: with the Multi-AZ option (AZ stands for Availability Zone, a physically separate but nearby data centre), RDS keeps a synchronised copy of the database in another zone. If the primary stops working, the copy takes over in 60-120 seconds, without anyone having to wake up in the middle of the night.
- Patching: AWS applies security updates in a time window you choose, so there are no surprises during working hours.
- Built-in monitoring: CPU load, disk speed (IOPS, the input/output operations per second the disk can handle) and active connections are already visible in a dedicated dashboard, with nothing to install.
- Storage that grows on its own: if the database approaches its limit, storage increases automatically without stopping the service.
The point is not that running a database yourself is impossible. It is that redoing all this by hand takes time, skills and continuous maintenance. RDS does not relieve you of making sure the application works well, but it takes 80% of repetitive, low-value operations off your shoulders.
Managed, but no less flexible
A common doubt is this: if AWS takes care of everything, how much room for customisation is left? Much more than you might think. The database (or databases, if the project needs more than one) created on RDS is a “real” engine, extensions included.
Take PostgreSQL, which among the engines supported by RDS has the richest extension ecosystem. If you need similarity search, useful in AI applications (think of chatbots with memory or recommendation systems), you can add pgvector. It introduces a dedicated data type for vectors and lets you run similarity searches directly with SQL queries, without maintaining a separate database just for that. If you work with geographic data, such as maps, routes or coverage areas, there is PostGIS, which adds functions and data types designed for spatial analysis.
AWS publishes the list of extensions available for each engine version. Enabling them usually takes a single SQL statement, without restarting the instance or touching the infrastructure. With pgvector, for example, you just connect to the database and run CREATE EXTENSION vector;. From then on, vector columns and similarity search functions can be used like any other native function.
The same goes for other widely used extensions. pg_stat_statements tracks the slowest and most frequently executed queries, and is great when you need to understand where the database’s time goes. TimescaleDB is designed for time series, typical of sensors, application logs and monitoring metrics. When evaluating RDS, keep in mind that choosing a managed service does not mean giving up the engine’s advanced features. It simply means delegating the surrounding maintenance to AWS.
When it beats an in-house database
Running the database yourself (so-called “self-hosted”) is not wrong in absolute terms, but it should be a conscious choice, not a habit. RDS makes sense when:
- the team is small or medium-sized and prefers to spend time on the product rather than on infrastructure;
- you need the service to stay up even when something goes wrong, without having to build that from scratch;
- there are regulatory (compliance) obligations requiring certified backups and data protected both at rest and in transit;
- you want to grow the project quickly without stopping to configure new hardware.
Self-hosting makes sense again when requirements are very specific (features not available on RDS, extreme optimisations, licensing constraints) or when you already have a dedicated team able to manage large databases. In that case the time invested pays off. In all other cases, the cost-benefit balance almost always tips towards the managed solution.
Why it is the default choice for many projects
In short: “managed” means backups, protection against failures and worry-free updates, with a ready-made control panel. The database remains extensible, with all the features of the engine you chose. And RDS pays off whenever your team’s time is worth more than total control over the infrastructure. In most modern projects it is the default choice, and even more so as the project grows.
Frequently Asked Questions (FAQ)
What is Amazon RDS?
Amazon RDS (Relational Database Service) is the AWS service for running relational databases such as PostgreSQL and MySQL in managed mode: AWS takes care of backups, failover, updates and monitoring.
What does a managed relational database mean?
It means the cloud provider takes on repetitive operations: automated backups kept for up to 35 days, failover, security patches, monitoring and automatic storage growth. The team remains responsible for making the application work well.
Can PostgreSQL extensions be used on Amazon RDS?
Yes. RDS supports many extensions, such as pgvector for similarity search, PostGIS for geographic data and pg_stat_statements for query analysis. Enabling them usually takes a single SQL command.
How long does a Multi-AZ failover take?
With the Multi-AZ option, RDS keeps a synchronised copy of the database in another Availability Zone: if the primary instance stops, the copy takes over in about 60-120 seconds.
When is a self-hosted database better than RDS?
When you need features not available on RDS, extreme optimisations or there are licensing constraints, or when you already have a team dedicated to managing large databases.