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.

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.