AWS Database Migration Service Reviews

We use this solution to get our data into Lakehouse with the CDC. So, Change Data Capture is also very important for us. AWS Database Migration Service has an inbuilt functionality for capturing change data.

The identifier of this solution informs us whether it's an insert operation, an update operation, or a delete operation. Since our main data is OLTP, the status of the order can keep changing; it can easily go from payment to successful and resend to cancel. 

This solution is very good at mini-batch processing if a user needs a latency between thirty seconds and two minutes. 

This solution can offer more tweaks where the latency can be brought down to fifteen seconds. DMS is not the go-to choice when it comes to data streaming, and the major reason is the latency issues because it's file-based and not message-based. So if DMS could offer such a solution, it has the potential to replace Kafka as well. DMS is more of a one-click setup in comparison to Kafka. 

I have been using the solution for two months. 

The solution is very stable. We haven't faced any downtimes yet. I would rate the stability a ten out of ten. 

I would rate the scalability an eight out of ten. We haven't faced any issues with scalability. As it's a background service that is actually replicating our data, DMS does not have an end user; it only turns the data into S3. When we connect to the database, that is when the end user comes into the picture. 

Our previous architecture was based on Debezium and Kafka, where Debezium was being used as a CDC tool. The learning curve for Debezium is much more steep as compared to AWS Database Migration Service. Also, with Debezium, if you are not using any external vendors, then you need to have DMS self-hosted on your own Kubernetes cluster. 

The setup process for this product is quite simple and AWS has provided very good documentation for this purpose. 

We implemented the solution in-house. 

I would rate the pricing a seven out of ten. 

I would rate the solution a seven out of ten. I would definitely recommend this product to others. 

We used the solution for live replication but faced many access challenges. We moved to make a full copy and then use column-level filtering to achieve incremental load. Over time, we get the necessary access permissions, allowing us to switch to live replication. We experienced a delay of roughly two minutes, which was not an issue for our use case.

When AWS Database Migration Service started working correctly, we had approximately 300 tables replicating from Oracle and other databases into AWS S3. Subsequently, any changes, such as full replication or percentage increments, could be easily accomplished by executing additional DMS tasks. DMS was configurable and straightforward to use. They were also scaling the scheduling of DMS drops. There are so many different options available.

We use an airflow instance on AWS to scale and schedule DMS tasks. This has allowed us to retire nearly 350 Informatica or injection jobs and consolidate them into DMS, a cost-effective service.

The most valuable feature is live replication at the cheapest price. GoldenGate also has a live application, but it is probably three times more costlier than what AWS provide.

We do some processes where we use JSON coding. It could be more user-friendly, like a drag-and-drop interface or studio-like experience. Additionally, It offers vertical and horizontal scaling mechanisms. There were some issues, particularly when the migration process was extended longer. The live duplication has a delay of two minutes, which can be an issue.

AWS have some languages to pass some parameters in configurations. When running a pipeline, batch or warehouse application, we pass many different parameters like configurations.

I have been using AWS Database Migration Service for three years.

There are some stability issues If it is a high data volume. Once the initial thing is sorted out, it's stable. The live application is stable, but when dealing with billions of records. We are trying to copy the data of billions of records from the source into the destination.

I rate the solution's stability a nine out of ten.

The solution’s scalability is good.

I rate the solution’s scalability a seven out of ten.

Technical support is great.

Positive

We have Kafka, Informatica, and Snowflake in our data pipeline. Sometimes, it's just a PySpark application running from Hadoop clusters or similar setups. Using a JDBC connection, this application connects to the source database, such as Oracle or another source.

We switched to AWS because it offers better infrastructure maintainability. Another advantage is that it utilizes behind-the-scenes MPP processing, providing all the benefits of a Spark application. So, to add or remove tables from the ingestion process, you make changes in the AWS console, and the PySpark application automatically adapts. With PieSpot, we had to maintain the infrastructure and manually deploy code updates. This involved several additional steps.

The initial setup is very straightforward. As long as you have the endpoints and the specifics from the source, it's a very simple thing to do.

We retired the need for an Informatica PowerCenter ingestion server, which saved us an estimated $100,000 to $150,000 per year in hardware and maintenance costs.

The product is cheaper than all platforms, excluding Spark. Adding the maintenance costs of all the servers and everything, Spark will be higher.

All of these options were previously available. For Informatica, you would need a separate Informatica cluster. Any application that requires DNS is serverless, so you don't need to worry about managing infrastructure. You can create a DNS service and start using it.

It could be a starting point for you, and if someone wants to use Oracle GoldenGate or another service, they need to purchase infrastructure. With AWS DMS, it's a matter of creating an account and starting from there. If you want to start, you could probably decide in the morning and by evening, you would have a DMS running on your AWS account.

Overall, I rate the solution a seven out of ten.

DMS's architecture is highly beneficial, allowing for scalable migrations of large datasets. The service's change data capture feature is precious, enabling synchronization between the old and new systems, and providing customers with real-time data visibility.

There could be enhancements in the product intelligently covering more scenarios to prevent crashes or failures. Improved dashboard capabilities for monitoring jobs and the ability to resume migrations from the last successful point instead of starting over would significantly enhance the user experience.

I have utilized Database Migration Service to migrate data from IBM DB2 to Amazon, from Oracle to PostgreSQL on RDS, and from SQL Server to AWS MySQL. 

DMS' seamless integration with other AWS services enhances its functionality and usability than other solutions. The continuous data replication feature also sets it apart, allowing for minimal downtime and real-time data synchronization during the migration.

The initial setup process is straightforward and user-friendly, provided that the operators understand the migration sizes involved.

The implementation strategy begins with assessing the size of the database to be migrated and understanding the customer's key performance indicators for success. It helps tailor the migration process to meet their expectations effectively.

Key features of DMS that are effective for large-scale migrations include the continuous data replication capability, which minimizes downtime, and support for heterogeneous database migrations. Additionally, it allows for multi-threaded processing and provides monitoring capabilities, making it easier to manage the migration process.

The monitoring capabilities are robust, providing detailed logs and metrics through CloudWatch. It allows me to track the status of migration tasks in real time, assess performance, and quickly identify and resolve any issues that arise during the migration process.

I encountered a data conversion issue related to changing time formats from UTC to a different format. By leveraging the transformation feature within DMS, I successfully converted the data to meet the customer's requirements.

I ensure that sensitive data is encrypted in transit and at rest using AWS Key Management Service (KMS). Additionally, I conduct thorough assessments of access controls and compliance requirements specific to the client's industry.

I stay updated with the latest features and enhancements related to AWS services by regularly attending webinars, participating in AWS training sessions, and following industry publications. Engaging with the AWS community through forums and conferences provides valuable insights and updates.

Overall, I rate the product a nine out of ten.

We're currently moving our whole database from AWS to Oracle. We want to avoid interrupting production systems, so we're using DMS to continuously replicate data from the AWS RDS database to the Oracle database in OCI. Once we're sure all data is consistent, we'll switch over to Oracle and shut down the AWS database.

This should minimize downtime to about 15 minutes, and all our services in AWS then point to the Oracle database.

For our simple requirement of migration, DMS is just a typical AWS RDS with an IPSec tunnel to Oracle. The most valuable features for us are the networking capabilities like VPCs and VPNs.

Currently, we're happy with DMS because it's simple and meets our needs. We're still syncing the data, but once that's done, we'll cut off the AWS database. Compared to Oracle GoldenGate, DMS is definitely easier to use. We haven't encountered any major difficulties.

The cost is a concern. We use DMS because of its simplicity, but the price could definitely be more competitive.

So, in my opinion, some potential areas for improvement are price and possibly supporting Oracle Autonomous Database (ADB) on AWS, as it's a powerful option.

Oracle ADB on AWS would significantly reduce our migration workload. Price and lack of ADB support are the main downsides of DMS for us right now. In fact, about 60% of our monthly AWS costs go towards database services.

We've been using DMS for a while to replicate databases between AWS and Oracle, mainly for backups and test environments.

I would rate the stability a six out of ten. It took us a while to get it running smoothly. It wasn't entirely straightforward. But once it was set up, it was stable. AWS support was helpful during the initial setup.

We haven't encountered any scalability issues so far. We might need to increase the database size later, but it's not a problem. So, I would rate it an eight out of ten.

We actually bumped up our support level for extra coverage, and they've been very helpful. We also have AWS expertise on our team, so there haven't been many difficulties. Overall, the support is good.

The biggest challenge we faced was setting up the IPSec tunnel between the two private networks. It took a while to figure out why they weren't communicating even though the tunnel was up. Luckily, our AWS networking experts managed to fix the routing issue.

Neutral

Currently, we're moving from AWS to Oracle. We're migrating our database, and that's already been taken care of. The issue with AWS has been addressed, and we no longer have any problems with it.

We're new to DMS. We decided to use it about three months ago. That's why we compared DMS with GoldenGate to choose the best option for migrating our database. 

The setup process was simple enough for us because our database is plain and doesn't have many blocks. It's just a typical cloud-based product, like most AWS services.

We use the enterprise and the AWS license, which is a bit expensive. We're consolidating our databases from AWS to Oracle, which we find more cost-effective. So, we're using an autonomous database in Oracle, a feature not offered by AWS.

We've been using AWS for a long time, including for non-Oracle services, and overall, we're very happy. It's much better than GoldenGate, which was a headache for us. 

Overall, I would rate the solution an eight out of ten. 

We were using the solution for the migration and replication of data.

AWS Database Migration Service is good for smaller workloads and provides compatibility.

The solution’s scalability and performance could be improved.

I have been using AWS Database Migration Service since it came up.

I rate the solution a six or seven out of ten for scalability.

The solution’s technical support is good.

Neutral

The solution’s initial setup is easy.

The solution’s pricing is reasonable.

AWS Database Migration Service is a cloud-based solution.

Overall, I rate AWS Database Migration Service a six or seven out of ten.

We looked for Oracle to Aurora conversion migrations. This has two parts, one is called the static table schema migrations, which is a one-time snapshot that we just stamp and load. The other is the CDC replications, or real-time streaming replications, heterogeneously from Oracle to Aurora. 

The solution is simple, which is key. 

AWS Database Migration Service is a huge product, and it takes a great amount of effort to reverse engineer what they do on the backend. It would be better if they did more troubleshooting at the moment. Currently, if something goes wrong, you get a message that says one thing that has nothing to do with the RCA, and it could be misleading. You aren't even sure which part was broken.

There is no connectivity to the source database or the target database. Any of those channels could break, and it becomes very hard to troubleshoot. 

I have been using AWS Database Migration Service since 2016.

The solution is stable. Typically, once the solution is up and running, and you don't change your application code, it will keep working. Even if it does break down, it will automatically recover itself and resumes from where it stopped.

The scalability of AWS Database Migration Service depends on how you define the scale. There are two considerations, one is the initial part of ETL replication. The other is the CDC part, which is after the full image replication is done. 

On the full ETL, you can scale. Meaning, even within the table you can do a parallel on the table level, or within the table level. After, you do a soft positioning for each range you want. A DMS would assign a process link up to that range, this speeds up the skip performance for the ETL.

As for the CDC, there are limitations. CDC is typically a single channel or single thread. That is because CDC is time-based and a binary transactional log. To do a parallel, you would have to do a lot of work. In our scenario, I could not use DMS. I had to use the in-house developer to do a catalog version of CDC.

My experience with Amazon's technical support depends on who I get for support. If I'm lucky to get someone with experience, the issue will be resolved right away. If I get an amateur, they will avoid answering any questions and send me tons of documents. 

Most of my questions are eventually fixed or solved. I would rate service and support a seven out of ten overall.

Neutral

In a typical deployment scenario, I set up the lead-only account on the source database. I make sure that I will not write anything to the source database to compromise the integrity of my source database. I have to write to the target database. Then the solution is ready for use.

Deployment of AWS Database Migration Service requires a POC first, then you make sure that everything is working and run it for about three weeks in an on-premise environment. Then you deploy, either manually or through the telephone, to an AWS production environment.

AWS Database Migration Service is very inexpensive. The cost is considerably lower than Agility or Oracle Golden Gate. We do not have a license for the solution. We are charged based on our usage.

We evaluated Oracle Golden Gate. They offer similar features to AWS Database Migration, but they lacked simplicity. With Golden Gate, you have to set up the entire enterprise software stack which requires so many steps.

We also looked into Aurora for replication, version eight. This product offers parallel replications of CDC, which is very useful. 

AWS Database Migration Service is most useful for a company that is trying to do partial applications for a short amount of time until the entire application is cut over from one place to another.

If you are considering AWS Database Migration as a solution for your organization, I recommend you pay attention to your CDC throughput, it is a single showstopper if you misuse it. I try to use it for our current application's traffic, which is about 30 megabytes per second. DMS would not be able to handle that in-house, it would just keep lagging.

Overall, I would rate AWS Database Migration Service a nine out of ten. It is a very useful product.

We use this solution to enable us to carry out heavy, data-level migrations across multiple ETL tools.

We particularly like that this solution has the facility to integrate with all ETL tools.

We also like that this solution provides us with high speed velocity, performance, scalability, and throughput for our data migration tasks.

We would like to see some improvement in the performance of large scale procedures, such as when we migrate from Oracle to csSQL.

We have been working with this solution for over five years.

We would rate this solution a 10 out of 10.

What I find most valuable in AWS Database Migration Service are these features: the full load and continuous data replication to heterogeneous endpoints.

There's a lot of room for improvement in AWS Database Migration Service, e.g. more endpoints to be supported, more control and transparency on the product and on how we get things done, and better operational support.

I've been working with AWS Database Migration Service for two years.

The solution is stable, but we have migrated a lot of those data sets to Qlik Attunity. I also worked for Qlik Attunity for consulting and database DMS.

AWS Database Migration Service is scalable, but Qlik Attunity is more scalable.

The technical support for AWS Database Migration Service is bad. They are still figuring out how to support their product. I've reached out to some AWS resources, but they don't understand the support.

The initial setup for the solution was moderate. It had some learning curve, but it was moderate. It was okay, and it was not difficult to learn.

How reasonable the pricing for AWS Database Migration Service would be, depends on where we are getting this data migrated from. Pricing for the solution is reasonable, but it could still be reduced.

I evaluated Qlik Attunity.

I use a lot of Qlik Attunity and AWS Database Migration Service.

I'm more of a consultant/engineer, so I use Database Migration Services to move data across different instances from on-premises to AWS, etc.

My advice to people who want to implement the solution is that there are alternate products. AWS Database Migration Service is still a good start, but an alternate product such as Qlik Attunity does a very good job, e.g. Attunity gives you more control.

I'm giving AWS Database Migration Service a six out of ten rating.