Oracle to Snowflake in under 60 seconds: redo logs, XStream, and the five things that break
Sub-minute Oracle to Snowflake is achievable. What is harder is keeping it sub-minute for a month. This post breaks down the latency budget and the five failure modes that decide whether you do.
Engineering · 2026-11-03 · Sumeta engineering
End-to-end latency is capture lag plus load latency, not one number. Oracle capture reads redo through LogMiner or XStream; Snowflake ingest runs through Snowpipe Streaming or staged COPY. Both legs have to be inside the budget.
The latency budget
| Leg | Typical contribution | Dominated by |
|---|---|---|
| Redo mining | Seconds | Log switch frequency and mining window |
| Change transport | Sub-second to seconds | Network and batching |
| Transformation | Sub-second | Whether it runs in-stream or in a separate tier |
| Snowflake ingest | Seconds to tens of seconds | Streaming vs staged COPY; warehouse size |
| Commit acknowledgement | Seconds | Offset commit discipline |
A separate transformation tier adds a hop whose latency grows with volume, and a scheduler adds a polling interval on top. Doing capture, transform and load in one job removes both additions — which is why the architecture, not the tuning, sets the floor.
Two capture paths
| Path | Mechanism | Licensing note | Latency |
|---|---|---|---|
| LogMiner | Reads redo and archive logs with a dictionary | No additional Oracle option required | Seconds, bounded by log switch |
| XStream | Oracle logical change stream API | XStream licensing applies | Seconds, cleaner stream |
The five things that break
- DDL. A new column or widened type changes the row image; without schema evolution in the same window the pipeline stalls or drops the field.
- Unsupported types. High-precision NUMBER, TIMESTAMP WITH TIME ZONE and intervals map differently in Snowflake unless mapped explicitly.
- LOBs. BLOB and CLOB capture amplifies log volume and breaks change-set size assumptions.
- Commit ordering. Parallel mining and multi-threaded loading can reorder rows for the same key, so the target reflects a stale update.
- Target backpressure. Snowflake throttling without upstream backpressure lets the offset fall behind and recovery cost grow.
Four of these five appear in the first week of a real migration. The fifth — commit ordering — appears under load, which is why a short POC can pass while production fails.
A verification plan
| Test | Duration | Pass condition |
|---|---|---|
| Steady-state capture | 24 hours | P95 lag inside budget; offset stable |
| DDL change | 1 change | Pipeline evolves or blocks deliberately, no data loss |
| LOB table | 1 table | Change set within size limits; no truncation |
| Target throttle | 1 hour | Backpressure applied; no unbounded offset growth |
| Recovery | 30-minute outage | Resume from offset; zero duplicates at the key level |
Replay production redo
Run the verification plan against a copy of your Oracle source before you commit.