Stelo + Google Cloud

Stelo can handle large-scale data transfers replication with sub-second latency. A single instance can support multiple sources and destinations without additional licensing. The Stelo model is independent of the number of cores of either the source or destination—so you only pay for the capacity required to support the transaction connections. This cost-efficient method merges source data flows into one stream, and then is applied to any number of subscribing destinations. Stelo delivers enterprise-level performance without enterprise-level cost.

Yes. Whether you want to deploy either entirely in the cloud or used between on-prem and cloud databases, Stelo’s deployment models are designed to maximize performance without sacrificing flexibility.

Cloud technologies enable choice. Some companies prefer to stream data into cloud-based delta lakes while maintaining their existing data warehouse; that way, they can take advantage of new technologies from companies like Synapse while maintaining their existing applications. Others would prefer to get rid of their in-house data center all together.

Stelo encourages customers to make improvements by integrating technologies that allow them to use their data better. Advancing data management strategy is not about displacing current software and hardware investments; it’s about making it easier to leverage new technologies that can unlock your data’s embedded potential.

Once replication source and destination databases have been defined, Stelo uses change data capture techniques to capture and apply only change data. Our multithreaded processing is far more efficient than other replication tools on the market, not only to provide near real-time data availability, but also best in terms of reliability and robustness. Stelo’s custom technology blurs the overhead of the WAN connection and effectively delivers near real-time (under 1 second) replication, regardless of whether it's going into cloud or on-premise locations. If your use-case requires sub-second latency at all times, we will size the replication instance according to your high-water mark of DML activity to ensure near real-time data availability.

Yes, Stelo has an automatic method to build out data warehouses, so we can do the heavy lifting for you. It works well whether you're doing a migration up to the cloud or are continuing with ongoing replication.

We encourage you to configure Stelo to create the destination tables on the SQL Server. In part this is to ensure the proper mapping of change data captured on the source system and the destination table. Also, if the Customer's High Availability (HA) software utilizes *AFTER images only for capturing change data, then Stelo must rely upon a synthetic column (the Relative Record Number or "RRN") to uniquely identify the row in the destination table, and it is unlikely that some tools such as the JDE tool would provide this column. Therefore, it is best to allow Stelo to create the destination, including this column for each table. Alternatively, if the HA software configures *BOTH images in the journals then we can dispense with the RRN column and just utilize any unique index (including a primary key) to identify rows.

Another issue that should be addressed in the planning stage is the use of Unicode data types on the destination SQL Server. We strongly encourage customers to use NCHAR/NVARCHAR data types for SQL Server as this provides the greatest fidelity when mapping data from IBM i EBCDIC to Windows and other non-EBCDIC environments.

Our recommendation is to allow Stelo to create the tables and exploit UNICODE data-types, and then use the tool to create any additional indexes.