Striim Reviews

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.

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.

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.