Amazon RDS vs MongoDB: What are the differences?
Developers describe Amazon RDS as "Set up, operate, and scale a relational database in the cloud". Amazon RDS gives you access to the capabilities of a familiar MySQL, Oracle or Microsoft SQL Server database engine. This means that the code, applications, and tools you already use today with your existing databases can be used with Amazon RDS. Amazon RDS automatically patches the database software and backs up your database, storing the backups for a user-defined retention period and enabling point-in-time recovery. You benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your Database Instance (DB Instance) via a single API call. On the other hand, MongoDB is detailed as "The database for giant ideas". MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding.
Amazon RDS and MongoDB are primarily classified as "SQL Database as a Service" and "Databases" tools respectively.
"Reliable failovers", "Automated backups" and "Backed by amazon" are the key factors why developers consider Amazon RDS; whereas "Document-oriented storage", "No sql" and "Ease of use" are the primary reasons why MongoDB is favored.
MongoDB is an open source tool with 16.3K GitHub stars and 4.1K GitHub forks. Here's a link to MongoDB's open source repository on GitHub.
Uber Technologies, Lyft, and Codecademy are some of the popular companies that use MongoDB, whereas Amazon RDS is used by Airbnb, Netflix, and Coursera. MongoDB has a broader approval, being mentioned in 2189 company stacks & 2218 developers stacks; compared to Amazon RDS, which is listed in 1435 company stacks and 526 developer stacks.
What is Amazon RDS?
What is MongoDB?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using Amazon RDS?
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
Used MongoDB as primary database. It holds trip data of NYC taxis for the year 2013. It is a huge dataset and it's primary feature is geo coordinates with pickup and drop off locations. Also used MongoDB's map reduce to process this large dataset for aggregation. This aggregated result was then used to show visualizations.
MongoDB fills our more traditional database needs. We knew we wanted Trello to be blisteringly fast. One of the coolest and most performance-obsessed teams we know is our next-door neighbor and sister company StackExchange. Talking to their dev lead David at lunch one day, I learned that even though they use SQL Server for data storage, they actually primarily store a lot of their data in a denormalized format for performance, and normalize only when they need to.
While we initially started off running our own Postgres cluster, we evaluated RDS and found it to be an excellent fit for us.
The failovers, manual scaling, replication, Postgres upgrades, and pretty much everything else has been super smooth and reliable.
We'll probably need something a little more complex in the future, but RDS performs admirably for now.
We are using RDS for managing PostgreSQL and legacy MSSQL databases.
Unfortunately while RDS works great for managing the PostgreSQL systems, MSSQL is very much a second class citizen and they don't offer very much capability. Infact, in order to upgrade instance storage for MSSQL we actually have to spin up a new cluster and migrate the data over.
Nearly all of our backend storage is on MongoDB. This has also worked out pretty well. It's enabled us to scale up faster/easier than if we had rolled our own solution on top of PostgreSQL (which we were using previously). There have been a few roadbumps along the way, but the team at 10gen has been a big help with thing.
We are testing out MongoDB at the moment. Currently we are only using a small EC2 setup for a delayed job queue backed by
agenda. If it works out well we might look to see where it could become a primary document storage engine for us.
Used for proofs of concept and personal projects with a document data model, especially with need for strong geographic queries. Often not chosen in long term apps due to chance data model can end up relational as needs develop.
Our PostgreSQL servers, where we keep the bulk of Wirkn data, are hosted on the fantastically easy and reliable AWS RDS platform.
We use Aurora for our OLTP database, it provides significant speed increases on top of MySQL without the need to manage it