Striim Reviews

My main use case for Striim is replication, bringing in data into Snowflake from Oracle and SQL Server.

For replication in my work, we have designed models where we have added our tables from the Oracle dataset and SQL Server based on the connections placed in Striim. It depends on how big or small the table is; we have divided those into different chunks. Based on the logs created in both platforms, SQL Server and Oracle, these logs are then fed into Striim server, from where Striim reads these logs and understands that the incoming records belong to which dataset and which operation needs to be performed for the CDC setup. In case it is bulk mode, it just drops the data, truncates the table, and reloads it into Snowflake.

Striim has positively impacted my organization as we have been able to set up Oracle EBS tables and SQL Server tables using one connection. The best part is that using one connection, we were able to add multiple tables to the CDC platform without much effort because it just requires the primary key to be set up on the source side, and then it works well, just by defining what exactly we require to do as part of the CDC checks. It has helped us a lot because it has significantly reduced hours of load that happened using the native ETL process, finishing in a few seconds and being close to real-time.

I can give you an example with a few Oracle tables, such as the PO tables and the sales order tables, which are extensive. They take hours to complete a full load or the CDC from the native ETL process because they have to scan the entire table to check for incoming records to either insert or update against them. With replication, it just takes a few seconds to analyze whether it is a new record or an existing record and perform the necessary operation.

Striim offers strong capabilities for real-time database replication. Its core strength is low latency, log-based change data capture, which continuously moves the data without putting heavy load on the source systems. It works especially well in Oracle environments and supports more than 150 sources and targets, including Snowflake, Databricks, and Microsoft Fabric, which is hot in the market right now. It handles the initial load and the ongoing CDC in one platform so we do not have to stitch together Kafka or similar processes ourselves. It offers high availability clustering with failovers and can run self-hosted or fully managed on cloud services.

The user interface is pretty good and self-explanatory, so there is no issue if a user lands in the application; they do not have to think more. It is self-explanatory, with all the navigation panes clear. However, the only thing is the searchability; if a user has to search which table belongs to which CDC application connection set up on Striim, it is quite extensive and not fruitful from a user interface point of view. Performance-wise, it is quite good; the queues are long, but as I mentioned earlier, the logs are not that self-explanatory that one can understand what exactly is going on behind the scenes.

Striim can be improved by making it transparent in terms of log monitoring and how issues are logged. The most important thing is to increase their documentation so that one can refer to their repository in case we are stuck.

Pricing is too high compared to other replication tools currently available in the market, especially Fivetran. I believe they should work on pricing and budgeting.

I have been using Striim for the past eight years.

Striim is stable.

Striim's scalability is good; it is wonderful, I would say.

Customer support is also good, as they are able to help us and resolve our issues when we reach out to them.

I would rate customer support a nine.

We have not evaluated previous solutions.

Striim is deployed in my organization using an on-premises server-client methodology, with the UI hosted on AWS.

Regarding time saved, we have saved a lot of time in replicating the dataset that Striim has resolved for us, and it is almost near real-time. I would not say it is fully real-time because it works on the queue methodology, but it is still near to real-time, so I have saved a lot of my time.

My experience with pricing, setup cost, and licensing is that it is costly. However, since it has helped us a lot, I would still recommend it to people. The only drawback is the documentation, error logging, and the user interface, which is not friendly enough to support more users. In case they want to attract more people, they should work on these areas to make it more lucrative.

We have evaluated Fivetran and other replication tools, which can be found on PeerSpot, but Fivetran was not solutionized at that time for handling Oracle tables from a security point of view, so we had to switch to Striim.

I would rate Striim a seven.

The reason I give it a seven is that it works well for Oracle datasets and SQL Server, but I deduct three points because it is not helpful for us when taking Salesforce as a source.

Additionally, I mention the documentation and error logging which is not available online.

Regarding Striim's AI capabilities, its governance and security are good, and they are currently managing it nicely; I have no issues there.

In terms of its accuracy and reliability of output, it is almost correct because they are reading the actual volumes of data coming into the application. It is almost correct, but not fully correct, as they still cannot capture the whole picture in terms of records from source to target; they only read the changes made to the table during that day or minute.

My recommendation to others reading reviews on PeerSpot is that Striim is a strong option for real-time database replication with low latency for change data capture, continuously moving data without putting heavy load on the source system. I would recommend it completely, especially for Oracle systems and SQL Server systems.

We were using batch data from an Oracle database, which was causing the Oracle database to slow down. We enabled change data capture and used Striim to read data from Oracle databases and ingest into Snowflake, which was our data warehouse.

We were using an ETL model using QlikView, which was taking several days for any software update. With Striim, that has come down to a few minutes. Whenever we do any releases, it would only take a few minutes for Striim to ingest into Snowflake. I would say we went from several days to maybe one to two hours for any release.

There were significant improvements because once we enabled change data capture, the database was not going down at all. The batch queries were taking so long earlier, and with change data capture, that load from the database has reducing significantly and the data was also reaching Snowflake in near real-time, approximately less than two minutes.

We were confidently in a situation to call Snowflake as a single source of truth and Striim had a critical role, without it the SLA would be much higher, and there would not have been much confidence in Snowflake.

The fact that you could start given what's called an Oracle SCN number, which is a starting position on where to read data from, is one good advantage of Striim. I saw Striim evolving from at least-once policy to exactly-once policy, which had a significant reduction in Snowflake costs. The ability to see checkpoints and restart Striim whenever we needed was also a good advantage.

Exactly-once policy is making sure that there is no additional compute cost on Snowflake. A checkpoint is helpful for me to figure out where Striim is in comparison to Oracle database commits, whether Striim is up-to-date or lagging behind. Checkpoints were also helpful to figure out which table is causing the delay. The checkpoint is at the app level and also at the table level, so I know if any one table is causing the problem, I can go to checkpoints and figure that out.

The checkpoints would help me to figure out where the problem was if there's any lag, but I had to do a lot of manual work to figure out where the lag is. Striim would not intuitively tell me the culprit table or database behind the lag. I believe that is an improvement Striim could definitely do.

Passwords were an issue. Property variables were not supported for passwords, meaning I had to make sure the password is manually populated. I believe if Striim could read from AWS secrets or its own secret mechanism to store the password, that would really save a lot of time so that I don't have to keep updating the password whenever there is any change.

The user experience of triggering alerts if there's any lag which Striim identified, which is outside normal processing time, could intrinsically be done by Striim. I believe that was lacking.

I would wait for Striim to tell me, instead of me going and validating whether Striim is lagging behind. If Striim could itself tell me that it's seeing a lot more volume than expected, that would really make me give it a higher number.

I used Striim from 2019 to 2022.

Striim was very stable. It would definitely slow down, but it wouldn't shut down.

Striim is deployed in a hybrid cloud, so that kind of helped us. Our licensing was based on the number of cores, so even if we have a high number of events on any given day, our license cost would not go high.

I did interact with support, and it was very positive. I had good experiences. They are all knowledgeable about what they do.

We evaluated Fivetran, Matillion, and Striim. We did not use Fivetran directly, but we did evaluate it because it was very expensive compared to Striim.

It's a combination of all of them. When it was taking 24 to 48 hours, we had a resource working and monitoring all throughout. Since it is now one to two hours, I would say it has saved employee hours and time.

It's very fair. We had a private cloud, and it's not based on the number of events. It was based on the number of cores and CPU cores.

I would definitely consider Striim before picking popular vendors like Fivetran. Also, make sure your licensing is in terms of memory or cores. Do not go with a licensing model based on the number of events. I would rate this review an 8 out of 10.

My main use cases for Striim day-to-day include maintenance, database performance, ensuring data integrity, managing transactional log overload, and simplifying data replication.

Zero-downtime cloud migration and live replication for offloading heavy reporting workloads are additional use cases that have been very helpful.

I ensure data consistency and integrity when using Striim for replication or migration, as this is my highest priority. I consider myself a proactive DBA in that regard.

Striim has impacted my organization positively by saving time, especially when we undertake many projects and day-to-day DBA activities. It was very helpful to ensure zero downtime during the migration process.

Regarding specific outcomes, there is definitely time savings because fewer resources are used, and it helps run faster while maintaining accuracy in following all scripts to ensure everything delegates smoothly without any manual interaction.

Striim's best features include the optimized log-based CDC and traditional replication methods such as transactional replication or trigger-based tracking.

Out of these features, I rely most on the zero-downtime capability for cloud migration, which is very helpful because we undertake many migration projects.

Striim's intuitive UI for monitoring, the flow designer, and the real-time console are straightforward and helpful.

Regarding Striim's governance and security capabilities, I find these very helpful, especially since I have used them heavily for migration. The security has proven quite robust without any issues.

Striim's accuracy and reliability are strong because, using Azure and Sybase, the process runs very smoothly. I believe it is safe to use during cloud migrations.

Striim typically integrates well with other tools in my environment. Once I start using it independently, it proves very helpful.

When troubleshooting issues with Striim arises, the features help by displaying problems easily, which saves time and provides straightforward navigation.

Striim can be improved by providing tools such as short videos or step-by-step manuals to clearly demonstrate its capabilities and help users learn quickly.

Regarding needed improvements, it is important to advance in the AI world. I am not certain whether this can be applicable for all RDBMS, but definitely more updates and features are needed, especially concerning AI integration.

The learning curve for new users getting started with Striim is manageable for those experienced in SQL and other RDBMS, but it can be challenging for newcomers. I recommend adding more learning resources.

I have been using Striim for more than five years, spanning both my previous company and my current company.

Striim has proven stable in my experience, as I have not encountered any downtime or disruptions.

When it comes to scaling with Striim as workloads increase, it has been quite helpful and could adapt easily, saving considerable time in delegation and follow-up because I only need to roll back scripts to ensure that nothing goes wrong.

In terms of scalability, Striim handles large workloads well, and I personally have not had any issues with that.

I have not needed to reach out to customer support because Striim has been an easy tool to use without any issues so far.

Prior to using Striim, we used other solutions, mostly Redgate Monitor, but Striim specifically addresses migration, making it our go-to tool.

I have seen a return on investment from Striim. Time savings are crucial since it saves considerable time, which positively impacts the return on investment.

We have not evaluated other options before choosing Striim. It was introduced to us, and we started using it and loved it.

Striim is deployed in my organization on-premise and in a private cloud, which has been helpful.

For our private cloud deployment, we heavily use Azure.

For monitoring Striim's performance and health in my environment, I heavily rely on Redgate Monitor, which proves very helpful.

My advice to others looking into using Striim is that if there is a trial period available for database administrators or anyone in the field, I am sure it can be helpful for everyone.

I would rate Striim an 8.5 out of 10 because, while there is room for improvement, its helpfulness and ease of navigation for any database administrator make this an accurate rating.

We use Striim to replicate the warehouse data to Google platform to generate reports.

We have developed a centralized server where we pull all the warehouse data through Oracle GoldenGate. Striim sits on Google Cloud Platform and the Striim agent connects to the compute server, reads the files generated by GoldenGate, and replicates the data. Additionally, we have Striim agent running on a standalone server that connects to OCI, reads the trail files from Oracle GoldenGate, and sends the data over to Google Cloud Platform.

Our aim was to use Striim to get the reports from Google Cloud Platform and it is working effectively, so Striim is useful for that purpose.

Striim is definitely my data migration tool and data reflection syncing tool. It reduces manual intervention because it automatically syncs the data from the warehouse. We can get the reports dynamically in real-time data reports. This saves time and helps to improve the business by analyzing the latest data.

We use Striim for normal BI. We do not use much workflow, though we have configured this workflow.

Striim is very easy to configure. You just install an agent and then configure it to connect to your server. Once the connectivity works fine, it is fairly a simple way to use Striim.

I would say Striim performance needs improvement because we use more GoldenGate, so I tend to compare GoldenGate with Striim. Comparing GoldenGate, I feel Striim will struggle a little bit when a batch process runs for a longer time and generates too much data. Otherwise, Striim is acceptable. With respect to certifications, I feel Striim is more expensive in terms of licensing. However, it is good if it is compatible with the product that we use.

Striim could provide more transparency in terms of the log files. When there is an issue, whenever there is an agent problem, we have to reach out to the Striim development team. If they were more transparent with their logs, we could debug and analyze ourselves. Additionally, they could provide more features with less licensing cost.

Documentation and compatibility are fairly straightforward. However, they could improve the documentation by showing how to configure with different platforms. Sometimes we rely on the development team to provide us with instructions whenever there is an agent issue. If there were more detailed documentation available, we could follow that and try to resolve the issues ourselves.

Striim is stable.

Striim can handle the data volumes effectively, but it can struggle a little bit if the data volume is too high.

If the transactions are not too frequent and if there are no long batch jobs, I would suggest going for Striim. If the data volume is comparatively moderate, I would recommend Striim.

Customer support is fairly good. When you contact them, they give you a response straight away and help you identify the issue and fix it. There is no problem with the customer support.

We used Oracle GoldenGate, and we switched to Striim because we wanted to use it in Google Cloud Platform.

The initial setup was straightforward.

I would say Striim saves time as it syncs the real-time data. Employees do not need to be dedicated to reviewing or monitoring Striim. The data team that you have in your company are the ones needed to see the data. No specific employees are needed to handle Striim.

Licensing was a bit more expensive because Striim has to read from Oracle GoldenGate trail files and also integrate them. However, I have no idea how much it was because I was not involved in that part.

We chose Striim as the first option.

The interview process is fairly good and covers all the questions about the product that the customer wants to know. This review has an overall rating of seven.

Our main use case for Striim is real-time data integration and change data capture, which we used to pull live transaction logs directly from IBM DB2 and stream them seamlessly into our modern cloud data warehouses.

A specific example of how we used Striim in our project is when we were migrating data to new and modern cloud data warehouses from IBM DB2 where we used the CDC feature of Striim. Real-time data integration and the CDC feature really helped us in that project.

From a BA perspective, our business users basically needed instant access to the live production data for analytics, which we provided them by using Striim. As a developer, I would say our bottleneck was that running heavy query workloads directly on the mainframe threatened our SLA transaction windows, so Striim helped in that perspective also.

The best feature that Striim offers in my experience is the dedicated IBM DB2 for z/OS connectors, which I really appreciated because it reads database logs directly, meaning we do not have to write custom extraction programs or alter existing application codes.

Using those dedicated connectors impacts our workflow by capturing instantly at the log level and streaming them out to the mainframe to cloud warehouses in real-time. In our organization, the real-time data is very important; any delay or wrong data transferred would impact a huge amount or cost to the company. It reduces the complexity of mainframe data format into clean streams and also reduces the time, and since it is real-time, it really helps us to transfer that real-time data.

Striim has positively impacted my organization by reducing the cost of doing it manually or through some other process for that particular project. By offloading analytics queries from the mainframe and utilizing log-based CDC, we drastically reduced our MIPS consumption, which is the mainframe CPU consumption and computing overhead during peak business hours. This reduction in MIPS reduced the overall cost.

I think the initial schema mapping tool in Striim can have a learning curve when dealing with deeply nested mainframe structures or complex copybooks. A more automated, BA-friendly interface for mapping would be a great addition.

I have been using Striim for one of our projects, which lasted for one and a half years.

In my experience, Striim is mostly stable; for that particular project, I had never seen any issues with the stability.

Striim is quite scalable.

The customer support has been excellent, and their engineers actually understand z/OS architecture and DB2 logs, which made troubleshooting during the initial setup smooth.

I personally have not used a different solution before Striim, but my organization may have been using a different solution previously. For me, it was my first project where I had to move data from mainframe DB2 to new data modern warehouses, so I have not personally used anything else.

I have seen a return on investment from using Striim, as I look for a system that requires minimal maintenance. Striim's continuous pipeline safely processes millions of daily transactions without data loss; my organization had millions of transactions every day and even in real-time, so it was quite good. We had saved a lot of money by reducing the MIPS, making it a good ROI.

We evaluated other options before choosing Striim, including building in-house ETL programs and traditional batch replication tools, but they were ruled out because they either put too much CPU load on the mainframe or could not deliver the real-time data. We chose Striim because it could deliver both reduced CPU consumption time and real-time data without any errors.

I rate Striim an eight out of ten, as it satisfies business requirements for real-time data while strictly protecting our mainframe performance and transaction speeds.

I chose eight out of ten because there are a few disadvantages, such as a few features that might be good, including the initial schema mapping tool that can have a learning curve when dealing with deeply nested mainframe structures or copybooks. As a BA perspective, a friendly interface for mapping would be good.

The accuracy of Striim is quite good; we tested it by matching the values we had in the mainframe system, and after loading into the new and modern data warehouses, the accuracy was great.

My advice to others looking into using Striim for mainframe development or modernization is to ensure that your mainframe developers and BA collaborate closely from day one. I suggest pre-defining your target cloud schemas and business rules so you can immediately unlock the power of that real-time stream.

Striim acts as the perfect modern bridge for legacy environments, keeping both our development teams and business stakeholders happy. We were happy to use Striim for that particular project, and I hope we can use it further. I also hope that the few features I would like to see added are integrated, so we can use it seamlessly.

My main use case for Striim is mostly for migration projects, where I migrate databases from SQL Server on Azure to Google Cloud SQL.

I can walk you through a quick specific example of how I used Striim during one of these migrations: there is an agent that I install on the source server, which starts the continuous data capture connecting to the source database, replicating all the database objects including tables with data, stored procedures, functions, and other database objects, with the target database specified as Google, but other source and destination combinations such as on-premises, AWS, and some other clouds can also be included.

One thing I would add about my use case of Striim is it is not very seamless; there were some failures encountered that were problematic, especially for very large databases where replication issues arise after a couple of days, making it difficult to backtrack and start the process again, effectively wasting a lot of time.

Striim is not deployed in my organization, as I used it strictly for a client's data migration while working for a consulting company; it was deployed on Azure, which is a public cloud, with replication to Google Cloud Platform.

Striim has impacted my organization positively as a data migration tool by streamlining data capture during migrations, replacing inefficient import and export methods that couldn't provide the latest data and changes, keeping everything synchronized with the CDC feature.

Regarding the time saved with Striim compared to previous manual methods, I believe these migrations are not even possible without it due to the size and complexity involved, and it greatly assisted in accuracy during the cutover phase, allowing for thorough database checks before final migration to Google Cloud Platform.

The best features Striim offers include continuous data capture and a smooth replication process from source to destination, along with a testing environment that allows for checks before cutting over and doing the DNS update.

What stood out to me about how Striim handles continuous data capture compared to other tools or manual methods is there was no other way I could see to migrate these very large SQL Server databases over to Google Cloud Platform over the internet, as Google Cloud Platform recommended; the CDC works nicely by replicating data as changes happen to the source database, running syncs to the target, and applying changes in near-real time.

As for additional features or schema conversion options, I cannot add anything at the moment since I didn't use many of the schema conversion options, focusing primarily on migration to Google Cloud Platform.

Striim can be improved in handling CDC connection or connectivity issues that impact data capture, as well as improving recovery options from errors, because starting from scratch with large databases wastes significant time.

I would add that there was a need for better documentation and support, especially regarding SQL Server, as I found it lacking during my experience while relying on support from Google individuals.

I chose a 7 out of 10 because of the need for better support, documentation, making the process slightly more efficient, and the cost, given that Striim is a licensed product with limitations on the number of databases.

There are no other improvements needed for Striim that I haven't mentioned yet, aside from support, documentation, and better handling of CDC failures.

I have been using Striim for a data migration of large SQL Server databases from Azure to Google Cloud Platform, where Google recommended using Striim for continuous data capture and replicating everything that we have on Azure on Google Cloud Platform.

In my experience, Striim was fairly stable, but there were a few instances where it failed during the CDC process after a couple of days, which complicated recovery.

Customer support was non-existent, with some documentation shared by Google personnel but no access to a customer portal for support tickets.

I did not previously use a different solution; the only data migration solution I employed is AWS Data Migration Service.

I have seen a return on investment that is more qualitative than quantitative, stating we migrated incredibly large databases in about five days, which is a much shorter timeline compared to several weeks if attempted manually.

My experience with pricing, setup cost, and licensing was limited to one instance, which was a factor, as we were working with Google professional services to acquire the necessary license for migration. We had to request additional licenses for the second database we wanted to migrate with Striim, facing restrictions around the schedule that impacted flexibility.

Before choosing Striim, I did not evaluate other options, as it was the recommended tool for SQL Server data migration by Google, and while I knew of AWS's DMS service, there wasn't another option from Google.

I would rate Striim a 7 out of 10, as it did the job but there are aspects that could be improved.

I used Azure as the cloud provider for deploying Striim.

My recommendation to others reading reviews on PeerSpot is to consider Striim's CDC requirement for migrations to Google Cloud Platform, as it might be the tool for you.

Primary use cases are mostly in the manufacturing domain. Manufacturers of semiconductors, solar panels, and windmills utilize our solutions. Specifically in the manufacturing domain, we provide preventive, predictive, and prescriptive analytics. We predict if there will be a failure in any of the components or equipment. We send alerts or triggers so that clients can take proactive decisions and make the necessary changes to prevent their manufacturing plant from failing. This provides a unified dashboard or view. For example, if a windmill or solar panel is going to fail in the next two weeks, they receive that trigger or alert immediately so they can take necessary actions to avoid it.

Striim is mostly for real-time change data capture. We integrate it with edge devices and sensors. If there is an anomaly or outlier, we detect it immediately and generate the alert. Databricks is mostly for low volume tickets and is not necessarily real-time processing but rather near-time processing. There can be a delay of two or three days before the report is generated. We use Databricks mostly for healthcare on-premises databases. Striim is mostly for real-time data capture. There is another complementary data platform called FactViewer as well, which operates along the same lines.

Trend detection is beneficial through the three Ps of maintenance: predictive, prescriptive, and preventive. When it comes to predictive analysis, the trend indicators inform our clients when a failure is going to occur in the system. The preventive part helps us suggest certain measures which they can take to avoid it. The prescriptive part provides recommendations or guidelines based on the historical analysis of the data, including patterns and correlations of earlier events or triggers. We identify those and give suggestions as to how they can avoid it in the future. Trend analysis is how we help our customers.

In terms of metrics, one major KPI is the turnaround time for report generation, which provides real-time insights. In relation to network infrastructure, the downtime and how many SLAs we have met are also important. If there is a network failure, there is a service level agreement that specifies acceptable downtime and when servers and infrastructure must be operational. These are some of the KPIs which we use for different industries. Mean time to detect failures or mean time to resolve a certain issue are also tracked. In a service desk situation wherein tickets are flowing in, we classify them automatically based on historical patterns without requiring triaging. We classify the tickets automatically and assign them to respective resources.

The Change Data Capture (CDC) feature is what I find most valuable in Striim. That is the most important feature. Its ability to integrate with all visualization platforms like Power BI and Tableau is also valuable. We can customize the reports based on the client's requirements. It is plug and play where you fetch an API and get the reports generated.

Striim allows both real-time and batch processing. We can decide the source and target and how the data will be ingested. Striim has the medallion architecture that allows us to decide how data will be extracted, transformed, and loaded. This includes both the ETL and ELT parts. Building AIML models on top of it allows a lot of collaborative work for data scientists and ML engineers. They can create their own experiments on top of that. Any organization has an AIML roadmap for five or six years. Based on the use case, we can design models on top of that. Striim provides a unified experience that comes in handy for users across domains.

The interactive dashboards help with failure alerts, such as if there is a pipeline which is failing. We have the new human in the loop feature where we can deploy agents. Not necessarily does there need to be a person who monitors the pipelines or builds them. We can deploy agents, and whenever there is a critical decision which has to be made, a human in the loop can receive a summary report of the situation and based on that, take necessary actions. Interactive dashboards is a very good feature in Striim.

We have integrated structured, unstructured, raw data, and data available on various social media platforms and ingested it into the lakehouse architecture. We cleanse it and build models on top of it. Based on the prospect's requirement, either real-time insight or near-time insight is provided. We have integrated various sorts of data, not necessarily clean or structured data, but data available on various platforms. We have ingested it, cleansed it, and built models on top of it so that they can use it as per their requirement.

The pricing is a bit on the higher end for Striim. If customers have that budget, Striim is a good option. However, if there are budget constraints, people generally tend to go with Databricks or Apache NiFi, or other various open-source tools that provide the same capability at much lower cost. Striim is good for large enterprises, but the pricing plans could be better.

My only major concern at the moment is the pricing part.

I have been using Striim for four plus years.

Striim's technical support is the best and at par with competitors. Since it originated from Oracle GoldenGate, the customer service, support, or whatever help is required is the best. There is no room for improvement there.

I would give Striim's technical support a solid nine.

We went with the partner route for both Databricks and Striim, which were gold partners with our organization. They provided us certifications for in-house resources. Any requirement that came up, we had their support from their solution architects in terms of designing the solution approach and sizing, determining the number of clusters or nodes required for data migration. That support was always there.

I use Striim to perform change data capture from relational databases to non-relational databases in my organization. I implement CDC with Striim by transferring data from Oracle Database to MongoDB in my environment.

I have a series of monitored tables where every time a change occurs in the source database, the data is transferred to the target database. The synchronization process is straightforward and efficient for my daily data flows.

I consider the best features that Striim offers to be great performance and a large number of sources and targets that can be connected.

Striim is capable of absorbing a large number of transactions, and the difference between the two databases is always less than a second, which demonstrates efficiency and highlights the variety of sources and targets I have used.

Striim has had a positive impact on my organization as it has solved stability issues that I had with other tools.

I think Striim could be improved with better pricing and enhanced documentation.

I have been using Striim for approximately three years.

I faced stability problems where the synchronization between the source and target databases would break. That problem has been completely resolved with Striim.

I would describe the scalability of Striim as very good, as it adapts well.

Before using Striim, I employed Debezium for data replication. I decided to switch from Debezium to Striim because Debezium was not completely stable.

I have seen a clear return on investment with Striim, particularly in the reduction of incidents. The incidents have disappeared completely since I have been using Striim.

My experience with the pricing, implementation cost, and licensing of Striim is that it is somewhat expensive.

I consider Striim to be a stable platform. My advice to other companies considering using Striim is that they should take it into account because of its great versatility. I have given this review a rating of eight.