Launch HN: MovingLake (YC S22) – Real-time data connectors for almost anything (app.movinglake.com)
Here are two demos: Whatsapp to Google Sheets (https://youtu.be/Qy4eInGgIhw) and Postgres to Webhooks (https://youtu.be/cmrkUan8o1w).
Moving data around is still difficult and a pain. Companies spend thousands of hours and lots of money making data pipelines. General solutions are difficult in that there are too many sources and too many destinations. It also entails a ton of schlep that no one really wants to deal with. At the same time, the API / data connector market is vast. Even when there are already multiple billion-dollar companies in the space, we continue to see big verticals unattended.
We previously worked at big tech as well as have been CTOs of Series B startups in Latam. We got into this problem when we had the experience of paying for pre-built data connectors, but at the same time having to do custom integrations to the API, at which point it didn’t make sense to have a paid data connector. After a few paid connectors and manual connectors we thought that there should be an event-driven, realtime data connector company which could solve all of our API integration needs in one go.
We also are not huge believers in operationalizing the data warehouse, i.e. the trend to use the data warehouse as a processing tool out of which data is extracted and pushed to other systems. Since data warehouses are built on an OLAP frame of mind, we think using it as a computation source for automated workflows is not the best idea. At MovingLake we propose using rather realtime connectors with a transformation pipeline which is specifically designed to do these things.
We combine polling with webhooks and websockets to provide a single reliable stream. If there's websockets, we use them. If there's webhooks we use them. If there's only GET endpoints then we poll as fast as the API lets us. Either way we ensure you'll get the data as fast as possible.
We provide destination adapters so that this data can be sent anywhere to as many destinations as you want for the same price. We provide CDC (Change Data Capture) plugins for databases to pull data as it is written and then send it anywhere. We also provide automatic JSON to SQL converters with Schema Evolution.
On our roadmap we still have to add the data transformation layer as well as add support for more bidirectional connectors.
“Get started” on our home page takes you to a “book a demo” thing, but there’s an open beta at https://app.movinglake.com which everyone is welcome to try out. Everything is free for now, though eventually we’ll have to charge. Although we wanted to charge a standard fee per event extracted, this would have tied our hands to deliver tougher-to-build connectors. So most of our connectors are charged at $0.00004 per event, but some which include scraping are charged higher (we want to be very explicit about which connectors are charged differently).
Please let us know what you think! Roasting our product would be super helpful :)
69 comments
[ 4.0 ms ] story [ 121 ms ] threadGoogle probably has better explanations for these, but to summarize:
* data connectors - connectors that allow you to get data from all systems you use in your organization, from databases to ERPS, to custom build systems.
* ETL - a method for moving data from your data sources to your datawarehouses (DWH) - extract from source, transform to desired format, load in you DWH.
* Snowflake - cloud based highly scalable DWH for structured and unstructured data
Data connectors, in the loosest definition possible, is simply a piece of software that moves data from one place to the other. This can be from database A to database B or (as in our case) from a given API into a database.
ETL stands for "Extract, Transform, Load", a process in which you get data from some place, clean it/do something with it, then store it into a desired destination. Probably this term is most frequently used in the context of data warehousing, in which you move data from one or more OLTP databases from the application side, into an OLAP database.
Finally, Snowflake is a very popular (and very cool) database focused on Data Warehousing needs.
I get kind of a "no code" vibe from it?
When I want to read data from an API, transform it and put it into a DB, my approach would be to write a few lines of Python. A script that does an http request to the API, transforms it and then writes the data to SQLite.
That seems much easier and more future proof to me than to bring in a 3rd party service.
When editing the launch blurbs, I usually tell founders to add explanations of any concepts or jargon that HN readers might not be familiar with. It's not always easy to know where to draw that line.
https://news.ycombinator.com/item?id=33360234 was pretty rightly flagged though - you're not supposed to put down other people's work in HN threads, especially not Launch or Show HN threads (https://news.ycombinator.com/showhn.html).
I asked about some terms and if they are common among the HN crowd. Ako replied that people who are doing enterprise software integrations know them. Then I ask if the HN crowd is nowadays people who are doing enterprise software integrations. (Because that is not what I would associate with hackers / startup founders. So maybe what initially was a community of hackers + startup founders is now a community of grown ups with enterprise jobs.)
Whose work have I put down by asking this?
Have curious conversation; don't cross-examine.
https://news.ycombinator.com/newsguidelines.html
If you say that wasn't your intent, I believe you, but I doubt that I'm the only reader who took things that way. It can be difficult to read intent accurately from short internet comments. Ultimately the burden is on the commenter to disambiguate intent (https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...).
To be honest I still find it hard to read that comment and not feel that it was being snide. If one takes your question at face value, it answers itself: of course the community is not "about that"—it's got all sorts of people doing all sorts of things.
Let me know if you still haven't gotten the email. I just tested it out and worked for me. But we can activate manually your user if you send me an email at andres@movinglake.com.
What is the pricing model ?
I would love a good real time connector for database like Oracle/postgres. There are few options like AWS DMS. But don't have many options for target
Pricing is connector-dependent and volume based. Most of our connectors are charged at $0.00004USD per event. You could email us to andres@movinglake.com and edgar@movinglake.com so we can discuss if we are a good fit for your needs.
> 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)
I need exactly this at work. However, my requirements are :
- it has to be "self-hosted", usually in my clients' VPC, sending data to a third party is a big no-no.
- most of them use SAP, Salesforces and many other esoteric CRMs & ERPs. It has to work for at least the most important ones.
- the target medium is usually the cloud provider's object storage (S3, ...), snowflake is quite rare. It also have to be flexible enough to support our own versioning strategy.
Would it work with your product ?
All of this is in our roadmap so we are glad to hear that we are on the right track. However we would love to know more about your last point. If you can email us to andres@movinglake.com and edgar@movinglake.com so we can discuss it, we would greatly appreciate it!
Can run on client's VPC infra.
Has connectors for SAP, Salesforce, some other CRMs, S3.
Not sure about own versioning strategy though.
Airbyte, looks "okay by the cover". If I want to go any further I would need to see what happens when I need to extract data from an esoteric, unsupported, undocumented, Java-based ERP that is no longer sold by its own developer. Unfortunately, I don't have the time nor the skills to do it. So, in the end, we let our clients write their own ETLs on their own stuff and match their datasets to our data model.
Unless I make the happy uncounter with a tool that focus on these forgotten ERP and CRM and don't completely break down when it encounters a weird FTP server serving "encrypted zip files", I'll just let it go.
Having a "Facebook ads" connector is not enough, and not where problems lies.
Gracias por el comentario! Supongo que en la traducción de inglés a español se perdió ahí algo.
Pero sí claro! Nuestra aplicación puede funcionar para pequeñas o micro empresas para cualquiera de nuestros conectores. Cualquier pregunta por favor escríbanos a andres@movinglake.com o edgar@movinglake.com
Because the href is `text-decoration:none`, this page appears to be blank: https://www.movinglake.com/docs/security/ only by hovering over "Data Privacy" does one realize it's a sub-page
I would guess in general the docs need some TLC, since https://www.movinglake.com/docs/destinations/http/ doesn't help me know what knobs I have influence over, as best I can tell "page 2" is the same as page 1 (https://www.movinglake.com/docs/destinations/page/2/), and for sure please do not require static AWS credentials (https://www.movinglake.com/docs/destinations/s3/) -- we actually have a Service Control Policy that outright bans the use of `iam:CreateAccessKey` across our entire AWS Org. Also, the "IAM view" is missing its protocol, causing the browser to think that the link is https://www.movinglake.com/docs/destinations/s3/console.aws....
This is actually the approach we take for connecting to Google Services.
Seeing a clearly fake testimonial immediately makes me lose trust in your product. It was pretty obvious the images in your testimonials were stock images, and a quick reverse image search confirms this (https://tineye.com/search/2f7aa5f73e0cee27b9ff54b1ad29cc8353...).
You obviously put a lot of work into your product, and it'd be a bummer to turn people off for something like that.
Regarding pricing, you are mostly right. It is connector-dependent and volume based. Most of our connectors are charged at $0.00004USD per event.
I think a major difference is that MovingLake seems to be managed-only with no self-hosted version currently.
Other differences I'm seeing is in the number of connectors and quality of documentation.
Absolutely, I think this area is under tapped currently. Good luck, fantastic area to work on.
"The #1 Real-Time API connector company"
You are just launching, so how could you already be #1?
https://www.google.com/search?q=%22The%20%231%20Real-Time%20...
1. How does this handle rate limiting on the target?
2. Who writes new connectors? Moving Lake only? Or can users create their own connectors (e.g. in Segment)?
3. You charge per event - but what are there batch connectors (also to overcome rate limits on targets)?
4. I'm curious why someone would choose to use Moving Lake over Segment? Are you beating them on pricing?