Skip to content
Notifications
Clear all

Just built a proof-of-concept that shows Claw can't match our current ETL pipeline speed.

2 Posts
2 Users
0 Reactions
1 Views
(@infra_auditor_nina)
Reputable Member
Joined: 4 months ago
Posts: 159
Topic starter   [#13498]

So the latest internal push is to migrate our core ETL pipelines to this new "Claw" service, promising a unified "low-code" experience. The pitch deck was predictably heavy on abstract "synergy" and light on actual throughput numbers. I ran a proof-of-concept against last week's production data payloads.

The results are, charitably, underwhelming. Our current batch of Python scripts with Celery and a tuned PostgreSQL instance processes the standard hourly batch in ~8 minutes. The Claw workflow, configured to their recommended spec, averaged 22 minutes. That's a 175% regression.

Key bottlenecks observed:
* **Orchestration overhead:** Their visual "node" system adds significant latency between simple transformation steps. Our scripts chain operations in-memory where possible.
* **Default concurrency limits:** Their platform enforces a default of 5 concurrent tasks per "pipeline," which is laughable for our volume. Support says we can request an increase to 15... after a capacity review.
* **Data shuffling:** Every step seems to write intermediate state back to their managed object store, introducing massive I/O wait. Our pipeline uses temporary disk buffers.

```sql
-- Example: Simple join & aggregate step
-- Claw's visual mapper generated this approximate query pattern.
-- Note the repeated CTEs and materialization hints.
WITH step_one AS MATERIALIZED (
SELECT user_id, SUM(amount) FROM source_a GROUP BY user_id
),
step_two AS MATERIALIZED (
SELECT user_id, region FROM source_b WHERE active = true
)
SELECT region, SUM(amount)
FROM step_one
JOIN step_two USING (user_id)
GROUP BY region;
```
Our hand-rolled version does this as a single hash join. The query planner isn't the problem—their framework's insistence on materializing every intermediate dataset is.

Before we entertain a "phased migration," I want to see:
* The incident postmortem from the last time Claw had a regional degradation. What was their MTTR?
* A detailed cost audit comparing our current infra bill to the projected Claw invoice at required throughput. Include egress fees.
* Their security attestations for data residency. Our current setup is already compliant with SOC2 and GDPR. Does Claw's shared-tenant model pass the same bar?

This feels like a solution in search of a problem. We'd be trading operational complexity for vendor lock-in and a significant performance hit. Convince me otherwise.

- Nina


- Nina


   
Quote
(@briang)
Eminent Member
Joined: 7 days ago
Posts: 20
 

That's a huge difference. Did your PoC include the cost of maintaining those custom scripts versus the Claw platform's total cost? Sometimes the slower tool wins if it drastically cuts support time.

The "data shuffling" point is key. I've seen similar latency in other low-code tools where each node is essentially a separate, isolated job. It's great for fault tolerance but terrible for raw speed.

You mentioned their default concurrency is 5. Is that 5 per pipeline, or 5 total across all pipelines for your tenant? That could be a major roadblock if you run multiple jobs at once.



   
ReplyQuote