Amazon RDS managed databases
The database, without the part where somebody has to remember to run backups.
Managed database
Chosen per project
Maintainable handover
Running your own database server is entirely doable and almost never worth it. Patching, backup scheduling, failover and point-in-time recovery are all solved problems, and RDS solves them for a modest premium over the raw compute.
What it does not solve is schema design, indexing or query quality — and those are where most database performance problems actually come from. A managed instance makes a badly designed schema highly available, not fast.
What we build with Amazon RDS
Any production relational database that matters to the business
Applications needing point-in-time recovery after a bad data change
Multi-AZ deployments where a few minutes of downtime is costly
Read-heavy reporting served from a replica
Where it fits — and where it does not
Good fit when
Standard PostgreSQL, MySQL, MariaDB or SQL Server workloads
Teams without a dedicated database administrator
Anything where a tested restore path is a requirement
Consider something else when
Workloads needing OS-level database extensions RDS does not permit
Very small projects where a managed container database is cheaper
The work RDS takes off your desk
Each of these is a task somebody has to do on a self-managed database, every month, forever.
Patching
Engine updates applied in a maintenance window.
Backups
Automated, retained, restorable to a point in time.
Failover
Standby in another availability zone, promoted automatically.
Monitoring
Metrics and slow queries surfaced without extra tooling.
How we work with Amazon RDS
Private subnets only
The database is never reachable from the internet; applications connect from inside the VPC.
Backups and PITR
Automated backups with a retention window, and a documented point-in-time restore that has been rehearsed.
Right-sized, then reviewed
Instance class and storage chosen from measured load and revisited once real usage exists.
Slow query visibility
Performance Insights and slow query logging on, because indexing problems show up there first.
Our typical Amazon RDS setup
| Concern | What we use |
|---|---|
| Engines | PostgreSQL, MySQL, MariaDB, SQL Server |
| Availability | Multi-AZ standby where downtime has a cost |
| Backups | Automated snapshots plus point-in-time recovery |
| Networking | Private subnets, security-group-restricted access |
| Scaling | Vertical resize, plus read replicas for reporting load |
Frequently asked questions
Usually with little or no application change, since the engines are standard. The work is in planning the cutover window and verifying the data afterwards, not in rewriting queries.
It roughly doubles the instance cost to remove most single-zone failure risk. For a system the business runs on, yes. For an internal tool that can be down for an hour, often not.
Only if the bottleneck was the hardware. More often it is a missing index or a query pattern, which we would look at first — that costs nothing per month.
Topics people search for
Services built with Amazon RDS
Cloud Solutions
Hosting designed around what your application actually needs, with the monitoring and backups that make it safe to rely on.
Custom Software Development
Software shaped around the way your business already works, instead of a packaged product you have to reorganise around.
Enterprise Software Development
Systems for organisations where several departments, sites and approval chains all have to work from the same data.
Software Maintenance
Keeping working systems working — including ones built by somebody else.
Tell us what you are trying to build
Describe the problem in plain language and we will tell you what it would take to solve it — the approach, the moving parts and the sensible order to build them in. No obligation either way.