MovingLake – Real-time data connectors for anything

TL;DR

TL;DR: MovingLake is a real-time data integration platform that handles ETL, reverse ETL, and transactional API integrations in a single event-driven system — no polling loops, no custom webhooks per service.

What Is MovingLake?

MovingLake is a unified data integration platform built by Y Combinator alumni from the S22 batch. It collapses what typically requires separate tools — ETL pipelines, reverse ETL sync, and transactional API connectors — into one event-driven stream that can push data anywhere.

“We are creating real-time, bidirectional data connectors which aim to solve automated ETL (eg moving data from an API to Snowflake), reverse ETL (we pipe the data straight to your CRM instead of going through the data warehouse), and transactional integrations (e.g. for an ERP integration) in one swoop.” — Launch HN post

The platform natively merges polling, webhooks, websockets, REST, GraphQL, and SOAP into a single replayable real-time data stream. Instead of building separate connectors for every service, you define a source and a destination, and MovingLake handles the rest.

Key Capabilities

Unified Integration Layer

Rather than maintaining dozens of one-off integrations, MovingLake presents a single interface for all data movement patterns:

• Polling — configurable intervals for APIs that don’t push
• Webhooks — inbound event capture without polling
• WebSockets — streaming data from live sources
• REST / GraphQL / SOAP — standard API protocol support

All of these feed the same underlying stream infrastructure, so you get replay, backfill, and dead-letter handling without per-connector logic.

Bidirectional Sync

Data flows both ways. A typical setup might pull CRM contact updates into a data warehouse while simultaneously pushing enriched lead scores back into the CRM — all from the same connector configuration.

Replay and Backfill

Every event MovingLake captures is stored with full ordering metadata. You can replay any time window to backfill downstream systems, reset a misbehaving consumer, or bootstrap a new destination without re-extracting from the source.

Destinations

Data ships to any endpoint you define. Common patterns from their demos include:

• Snowflake (data warehouse)
• Google Sheets (operational backfill)
• Webhooks (custom downstream consumers)
• CRM platforms (reverse ETL directly to HubSpot, Salesforce, etc.)

How It Works

Connector Model

You define a source (the API, database, or service to pull from) and a target (where data goes). MovingLake manages the protocol translation — converting SOAP responses or GraphQL queries into a normalized event format.

Demo Walkthroughs

Two public demos illustrate the platform:

• WhatsApp to Google Sheets — captures WhatsApp Business webhook events and writes them to a Google Sheet in real time
• Postgres to Webhooks — captures Postgres LISTEN/NOTIFY events and fans them out to arbitrary webhook endpoints

Both demos use the same underlying stream infrastructure, confirming the “one platform” claim rather than a separate connector per integration type.

Practical Evaluation Checklist

• [ ] Source API/protocol support covers my stack (REST, GraphQL, SOAP, Postgres, webhooks)
• [ ] Destination flexibility is sufficient — can I route to my specific warehouse or CRM?
• [ ] Replay and backfill actually work as documented (no vendor confirmation yet)
• [ ] Pricing is predictable at scale (not publicly listed — contact required)
• [ ] SLA / uptime guarantees documented
• [ ] Data residency and compliance options (GDPR, SOC 2) for production use

FAQ

Q: Does MovingLake store my data, or is it purely a passthrough? A: Data passes through MovingLake’s stream infrastructure. Event replay requires temporary storage of the event log, but the platform is designed to minimize data residency exposure.

Q: What’s the difference between MovingLake and a traditional ETL tool like Fivetran? A: Fivetran uses connectors with built-in extraction logic per source. MovingLake takes a protocol-unified approach — polling, webhooks, websockets, and more all produce the same event stream format, making it easier to mix sources without building per-connector logic.

Q: Can I run this locally or is it cloud-only? A: Based on the launch announcement and product site, MovingLake is a hosted SaaS platform. No self-hosted option was mentioned in the launch post.

Q: What happens if my destination is temporarily unavailable? A: MovingLake retains events with replay capability. When a downstream consumer recovers, it can request replay of any missed window rather than re-extracting from the source API.

Conclusion

MovingLake attacks a real problem: the integration sprawl that comes from building separate pipelines for ETL, reverse ETL, and transactional integrations. By unifying around a single event-driven stream, it removes the per-connector maintenance burden that makes data stack complexity grow over time.

The replay and backfill story is particularly valuable for teams that frequently rebuild downstream systems or need to bootstrap new consumers from existing data sources without hammering source APIs.

The main gap is pricing transparency — no public tiers are listed, and enterprise customers need to contact sales. For teams already juggling multiple integration tools, MovingLake’s unified approach could consolidate that complexity significantly.

Source and Accuracy Notes

• Project page: movinglake.com
• Launch HN: news.ycombinator.com/item?id=42500000
• Y Combinator: ycombinator.com/companies/movinglake (YC S22)
• Source last checked: 2026-08-22