Skip to content
YC Root AccessYC Root Access

Artie: Real Time Data Streaming For The AI Age

In this episode of Founder Firesides, YC Managing Partner Jared Friedman talks to the founders of Artie (S23), Jacqueline Cheong and Robin Tang, who have just announced their Series A. Artie is a real-time data streaming platform for cutting edge companies, streaming up-to-date and reliable data between systems in real time.

Jared FriedmanhostJacqueline CheongguestRobin Tangguest
Jan 26, 202626mWatch on YouTube ↗

EVERY SPOKEN WORD

  1. 0:00 – 0:05

    Intro

    1. JF

      [upbeat music]

  2. 0:05 – 1:00

    Artie overview and Series A announcement

    1. JF

      Really excited to be sitting down today with the founders of Artie, Robin and Jacqueline, who just announced that they've raised a Series A. Congratulations on the Series A, guys, and thanks for joining us.

    2. JC

      Yeah.

    3. RT

      Thank you.

    4. JC

      Thanks so much.

    5. JF

      To start with, do you wanna just tell everybody what Artie is, and perhaps you can tell everyone about the Series A you guys just raised?

    6. JC

      Yeah. So Artie is a real-time data streaming platform. Um, what that means is, we help companies move data across their systems in real time. So imagine you have production data in Postgres, we will stream it over as changes happen into, you know, a Snowflake, as things are changing under the hood. We just raised a 12 million Series A from Dalton Caldwell, Paul Buchheit, and Brian Berg from Standard Capital, and we're really excited to be chatting today.

    7. JF

      Let's rewind back to the beginning. You guys were in Summer '23. Maybe tell us a bit about, like, how this got started and how you ended up working on this.

  3. 1:00 – 2:00

    Origin story: the persistent pain of “data isn’t fresh enough”

    1. RT

      Yeah. So this all started with my background where, like, d- depending on the various companies and roles I was at, we were either using, like, you know, Databricks or BigQuery and what have you, and the same thing kept popping up. I would be asking my data team pe- to ask for faster and fresher data. When I was working on growth at Opendoor, I wanted faster data so I can experiment, do faster experimentation, or I wanted to operationalize certain use cases using, like, a tool like Retool. And I was basically always told some variant of, like, "This is too hard for my data team," or, like, "We don't have the capability or resourcing to build this, so, like, unless it's a company P0, don't, don't, don't bother." So then I tried to buy a tool. Then I discovered, you know, the managed batch players out there and found that they were, like, really good at getting set up, really good for SaaS data sources, like HubSpot and Zendesk, but completely different buyer persona, right? Where, like, you know, the SaaS data sources, they're more geared towards business users or, like, marketing users, and what I wanted was a production database, and that's more geared to our, like, infra and platform engineers. And because

  4. 2:00 – 3:24

    Why building CDC connectors in-house is a trap (and why Artie had to exist)

    1. RT

      of the fact that, like, they just weren't able to keep up with the load, we ended up having to try to build something in-house. I had a team try to build this for about a year, and by the end of it, it wasn't production-ready. So then I pulled the plug and then started to ask questions around, like, at... Every company at a certain data scale needs to build a tool like this to be able to use some sort of, like, a change data capture mechanism, and just spending a year to two years building a Postgres to Snowflake connector just seems weird. Like, it seems nonsensical.

    2. JF

      Yeah. It seems like not anyone's else's core competency.

    3. RT

      Exactly.

    4. JF

      Like, you should be focused on your product, not m- not building, like, a weird data connector.

    5. RT

      Yeah. And then that's when I was like, "Okay. Well, if it doesn't exist, let me just build it myself," and that's what, that's all, that's, that's ultimately what started Artie.

    6. JF

      What are the companies where you saw this problem?

    7. RT

      When I was at Zendesk, we ended up rebuilding, like, our enterprise data warehouse a few times. We were already using change data capture, so Zendesk open sourced this tool called Maxwell. We were trying to use that for, like, data integrations, and just doing that alone was still too hard. Then I joined Opendoor, Postgres to Snowflake, and again had the same problem. We were trying to build something like this but just didn't have the capabilities to really build it.

    8. JF

      When you tried to build this before Artie at-

    9. RT

      Mm-hmm

    10. JF

      ... these previous companies, engineers spent, like, a whole year-

    11. RT

      Mm-hmm

    12. JF

      ... trying to build this and, like, failed to build it.

    13. RT

      Mm-hmm.

    14. JF

      How long did it take you to build it at, like, at, at, as Artie? [laughs]

  5. 3:24 – 4:17

    Early build timeline and YC-era “fake it till self-serve” onboarding

    1. RT

      Okay. Before AI got good, we w-

    2. JF

      [laughs]

    3. RT

      When we started this, it took us about six months to build this. Now, if I, if I had to, like, th- really, if I, if I had to do it, redo again, probably would take, like, two to three months.

    4. JF

      Wow.

    5. RT

      But did take six months because it was, it is a hard problem.

    6. JF

      Yeah.

    7. RT

      And, you know, during the batch, it was funny because we didn't fully make our product, like, fully self-serve yet. We onboarded our first customers using Google Sheet and, like, tracking backfill progress using that.

    8. JF

      Yeah.

    9. RT

      And then during the YC batch, we made it so that, like, it appeared self-serve so that customers can onboard tables, but what it would do ultimately was send me a Slack ping to be like, "Hey, go onboard this table." And it w- it's funny because we had a customer in New York. They onboard at 8:00 a.m., so it's, like, 5:00 a.m. for us, and then they're like, "Wait, it's been stuck for a couple hours." By the time I woke up, I saw, I'm like, "Oh, [laughs] I need to, I need to kick off a backfill for this." And then-

    10. JF

      Yeah. [laughs]

    11. RT

      Yeah. It took us, like, probably almost 10 months to fully make this product self-serve.

  6. 4:17 – 5:23

    What existed at YC application time: infrastructure first, sales skills later

    1. JF

      Got it. Do you remember how far along you were at the time that you applied to YC? Had you started writing code? Did you have any of this working?

    2. RT

      Yeah.

    3. JC

      Yeah. We started probably, like, six to eight months before YC was when the idea really started to come together. So by the time we started YC, the base infrastructure was built. We had to build the UI and to make it usable, but the underlying infrastructure was built, and we spent most, most of YC actually learning to talk to customers, how to sell, and, and all of that stuff.

    4. JF

      Yeah. Let's talk about that 'cause the thing about this product is it's like, unlike a lot of SaaS tools that YC companies make, this is infrastructure. Like, w- companies who are using this, if it breaks, it's, like, a big deal.

    5. JC

      Mm-hmm.

    6. JF

      And so, like, has to be reliable from the get-go. And also, I assume really small companies don't have this problem, right?

    7. JC

      That's correct.

    8. JF

      So, like, the only people who have this problem are, like, pretty big companies-

    9. JC

      Mm-hmm

    10. JF

      ... where it's, like, pretty high stakes to deploy this kind of infrastructure. They have to rip out some existing thing and replace it with Artie.

    11. RT

      Yeah.

    12. JF

      How did you guys get your first customer data?

  7. 5:23 – 8:47

    Landing Substack: mission-critical first customer via cold email + POC

    1. JC

      So our first customer was Substack, and, um, they, what they needed was they had this, like, massive Postgres database, and they needed a system that could reliably get data out without impacting or putting any load on their application, and then reliably move it into Snowflake with relatively low latency. And I think there, there definitely was hesitancy. Like, this is-You know, just to set a baseline, anything that needs to be real time is by definition like mission critical.

    2. JF

      Yeah.

    3. JC

      So this is like, this happens to all our-

    4. JF

      And this was your first deployment.

    5. JC

      Yes.

    6. JF

      So like you had built this product that l- literally nobody was using.

    7. JC

      Yeah.

    8. JF

      Substack has like millions of users.

    9. RT

      Yeah.

    10. JC

      Mm.

    11. JF

      And they were considering deploying this thing in production-

    12. JC

      Yeah

    13. JF

      ... for their millions of users that no one had ever used before.

    14. JC

      Yes.

    15. JF

      Okay.

    16. JC

      Obviously, you know, they, they learned about us. They were very intrigued. Um, they gained confidence through the POC actually, like really testing us, pushing through billions of rows, putting very tight constraints on what we could, how we could connect to their database, and then they saw that it worked. But I think the alternative is they would have to build it themselves. And s-

    17. JF

      And had they gone on some journey like what Robin was talking about, where they'd tried to build this thing for a year and like it hadn't worked?

    18. JC

      Yeah.

    19. RT

      Or something like that, right.

    20. JC

      I mean, there are companies that have built this in-house, and they, they are, you know, incredible, like, uh, DoorDash, Netflix, Instacart. They have massive teams that have spent not just one year, but like multiple years making it truly production ready to guarantee data integrity, guarantee there's never out of order writes. And then there's always failures, but how do you recover from a failure without having to do something like very disruptive? Those are all edge cases and failure modes that they've baked in into their platform. Today, what we, what we have is something that, what they have, but like packaged into a product. Back then, we obviously didn't have all of the bells and whistles baked in, but even then it was, "You guys need to hire a team of maybe five to seven somewhat distributed systems understanding, knowledge, maybe one person that has built it before just to ensure that there's a higher success rate of this project. And then give them like six to 12 months." Um, and so the alternative, if it worked, and it was one-month POC, um, it, it just seemed like a better, lower-risk way to go.

    21. JF

      And how did you get in touch with them?

    22. JC

      It was a cold email.

    23. JF

      It was a cold email.

    24. JC

      It was a cold email.

    25. JF

      Wow. So-

    26. JC

      And this was when we were very bad at writing cold emails. [laughs]

    27. JF

      [laughs] But I guess just the need was so great that they just went with it anyway.

    28. JC

      It was-

    29. JF

      If you were just making something that they really needed.

    30. JC

      Yeah. I even remember the timing. It was a cold email that went out around like between 8:00 or 9:00 AM. Within an hour, uh, the head of data responded and was like, "Can you chat this afternoon?"

  8. 8:47 – 10:18

    Why growth is lumpy for infra: long gaps between ‘big bets’

    1. JF

      Wow. Because every one of these deployments is so mission critical, this is not the kind of company that like gets hockey stick growth early-

    2. JC

      No

    3. JF

      ... or easily.

    4. RT

      Mm-hmm.

    5. JF

      'Cause every one of these customers is like Substack.

    6. RT

      Yeah.

    7. JF

      They have to make a really big bet on you guys that you're gonna run a foundational piece of their infrastructure.

    8. RT

      Yeah.

    9. JF

      What were the first six months of YC like?

    10. JC

      It was pretty slow. Um, I mean, we did manage to get, during YC, about like seven or eight customers.

    11. JF

      Okay.

    12. JC

      Um, and most of them were smaller, uh, more like early adopters. But, um-

    13. JF

      Substack, if I remember correctly, was really the first big customer that took-

    14. RT

      Yes

    15. JF

      ... a bet on you for like a long time.

    16. JC

      Yes.

    17. RT

      Yes.

    18. JF

      Like that one came really quickly-

    19. JC

      Yes

    20. JF

      ... right off that cold email, but then it took... How long did it take before you got another Substack scale customer?

    21. JC

      It probably took another nine months-

    22. RT

      Yeah

    23. JC

      ... before we had another one.

    24. JF

      You know, that's a funny parallel, 'cause I don't know if you guys know the origin story of Substack, but they had the same thing.

    25. RT

      Oh.

    26. JC

      Really?

    27. JF

      Where their, their very first customer of Substack was this really famous blogger.

    28. RT

      Mm-hmm.

    29. JF

      And, um, Substack was in, in, in my group as well. And so, um, I remember during the batch, they thought, because the first customer was so big and came so quickly, they thought that was just like how it was going to be.

    30. JC

      [laughs]

  9. 10:18 – 13:12

    Reaching $1M ARR with a tiny team: disciplined hiring and founder-led sales

    1. JF

      One thing that's always impressed me about the two of you is how much you've been able to build with initially just Robin, and then with like a very small team.

    2. JC

      Mm-hmm.

    3. JF

      Um, 'cause like that whole first summer when you were deploying to Substack and these seven customers and running all, running, you know, I don't know h- how, how much data, like millions of rows.

    4. RT

      They were doing about one to two billion during the batch per month.

    5. JF

      Yeah, like one to two billion rows of data.

    6. RT

      Yeah.

    7. JF

      It was just the two of you working on this, right?

    8. JC

      Mm-hmm.

    9. JF

      [laughs] When you crossed a million ARR, which is a, a, like a, a, a huge milestone for a company. Typically, companies at least, you know, in, in the pre-AI era would have, you know, 10 to 20 employees at the point that they, they crossed a million ARR. How, how, how big was Artie?

    10. JC

      Uh, it was the two of us and two engineers.

    11. JF

      At a million ARR?

    12. JC

      Mm-hmm.

    13. JF

      That's pretty crazy. W- how do you guys explain that? Like what did you do that made that possible?

    14. JC

      You know, we, I think we followed the YC advice. Um, we take all the YC advice very seriously, and one of them was we have to be very careful about how we grow. A bad employee is worse than no employee at all. Um, and then the other one was, you know, like what is the biggest constraint to growth? Um, like don't hire unless that position is literally the biggest constraint to growth. And maybe we went a little too far-Um, [laughs] with some of that advice-

    15. RT

      [laughs]

    16. JC

      ... because there are periods of times, like even right now, we're, we're... We just feel so understaffed because there's so much that we need to do now. Um, and we're, we're, we're changing that, and we're accelerating hiring. Um, but at the time, you know, because sales and having these enterprises trust us to power mission-critical, um, infrastructure, I wanted to keep that within myself because the more that I can be on the ground talking to customers, understanding, uh, objections, fears, uh, understanding how they're using the product, the better, the faster that we can actually iterate. And so I think actually having sales, having the founders run sales and the engineering side so closely h- actually made us move a lot faster. Like people are constantly surprised by how quickly feature requests, feedback gets implemented into, into the product.

    17. RT

      Yeah.

    18. JF

      'Cause during the batch, you were just building the product-

    19. RT

      Mm-hmm

    20. JF

      ... and you were just selling the product-

    21. RT

      Yeah

    22. JF

      ... and that's all there was.

    23. JC

      Yep.

    24. RT

      [laughs]

    25. JC

      I was basically a very good SDR-

    26. JF

      [laughs]

    27. JC

      ... for the first year, year and a half of the company.

    28. RT

      Yeah. We're a Venn diagram that doesn't intersect. [laughs]

    29. JF

      [laughs]

  10. 13:12 – 16:49

    Married co-founders: deciding to jump in and how it changes the work dynamic

    1. JF

      Actually, that's a good segue to, um, the two of you. You guys have a interesting co-founder relationship because you are also married.

    2. RT

      Yeah.

    3. JC

      Yeah.

    4. JF

      Do you guys wanna talk about what it's like to be married to your co-founder, and may- maybe even how you guys decided to work together? W- was it-

    5. JC

      Yeah

    6. JF

      ... was it, was it, was it something you guys were worried about i- i- initially?

    7. JC

      We met around like 10 years ago, roughly this time, in San Francisco. Um, when he actually... So he was at Opendoor, and he was telling about this like streaming pipeline that he, he was gonna build, and when he came to me about the idea, um, I was actually very skeptical. I n- wasn't deep in the space, and I was like, "This sounds like something very practical. I feel like someone already built it, and we just need to do some research and f- and figure out the market."

    8. JF

      Mm-hmm.

    9. JC

      Um, and then I got deeper and deeper, and I basically got sucked in because I was talking to these engineers, and I realized how much time and effort was being spent dealing with this problem.

    10. JF

      Mm.

    11. JC

      So I was like, "Okay, seems to be a structural thing, like this is the way it's done. It seems very broken. There seems to be a pretty clear opportunity here." Um, and funny enough, there was a slight bit of concern because we, we just didn't see a lot of examples out there where, you know, married co-founders creating great companies together.

    12. JF

      Mm-hmm.

    13. JC

      Um, but we... It was really funny. We basically looked at like, "Okay, how do we like, how do we fight normally?" And like, are they productive? Do we feel comfortable how we fight like normally, that it would translate well into-

    14. JF

      Mm-hmm

    15. JC

      ... you know, in a working environment? And basically, we got enough conviction off of that, and we kinda jumped head first into it. There were a lot of things that we were a little like-

    16. JF

      You guys both had jobs, right? You, you-

    17. JC

      Yeah

    18. JF

      ... y- you both quit your jobs to do this.

    19. JC

      Yep.

    20. JF

      Yeah.

    21. JC

      Yep, we quit at the same time.

    22. RT

      [laughs]

    23. JC

      It was like January 1st or 2nd that year, and we just jumped head first. We, we were a little naive. We w- we knew, we were like, "This is such a great idea."

    24. JF

      [laughs]

    25. JC

      Um, I think if Robin just builds it and I set up the business, uh, you know, peop- people will just, people will just buy it. Um, that was the initial, initial thought. So we were like, you know, th- this is, this is pretty compelling.

    26. JF

      What has it been like working together for the first time in your lives? 'Cause you guys met and had, you know, a more normal marriage-

    27. JC

      [laughs]

    28. JF

      ... before you decided to also be, be co-founders.

    29. JC

      Yeah.

    30. JF

      How has it changed your relationship and your lives?

  11. 16:49 – 17:27

    Work-life boundaries (or lack thereof) when building high-stakes infra

    1. JF

      Do you guys have rules to keep a work/life boundary, or do you not try and try to just like th- th- take advantage of the fact that like your, your work and your life is all inextricably caught up?

    2. JC

      We have had discussions about it, and we've decided it's not a good move. [laughs]

    3. JF

      [laughs]

    4. RT

      [laughs]

    5. JC

      I don't think we have a life outside of Artie at the moment. [laughs]

    6. RT

      It's hard. [laughs]

    7. JC

      There, there would be nothing else to talk about. [laughs]

    8. RT

      [laughs] Yeah.

    9. JF

      During the process of building Artie, you guys solved some really difficult tactical challenges, like this is why people are paying you a lot of money for this product.

    10. RT

      Yeah.

    11. JF

      This is really hard to build.

    12. RT

      Yeah.

  12. 17:27 – 20:53

    Battle scars of real-time data: backfills, edge cases, and undocumented ‘right ways’

    1. JF

      Do you wanna talk at all about... I don't know. Are any of those interesting to talk about?

    2. RT

      Yeah. Data processing, honestly, is like a series of accumulated battle scars that you just learn and build resilience towards, such that when you deal with another edge case, you're just like better prepared for it. Because like, you know, like we have customers that, you know, try to get something like, like an Artie-like da- like architecture set up. You can set it up relatively easily on your local environment, but it's a completely different scale when you bring it into production. Scale in terms of, not, not just in terms of volume, but also like-... complexity and unknown unknowns. So we've, we spent, we're still spending time learning. Like, just little things like why does MongoDB allow month to be greater than 12? [laughs]

    3. JC

      [laughs]

    4. RT

      That doesn't make sense. Or like, a year can break. Why, why, why, why? Like, how does that work? Like, just little things like this that we just have to constantly keep an accumulation of, like, these are the known problems. How do you deal with this? So build that. Then the second thing becomes, like, okay, we, we built a backfill method that's like we do a online backfill. So like, what companies like Netflix have built is called DB Log. What that does is like they basically backfill and stream at the same time, and the streaming changes get accumulated into, like, a Kafka or something similar. And once you're done with the backfill, you drain the s- Kafka topic, right? So that your database on its own doesn't just accumulate, like, changes while you're backfilling, 'cause backfilling can take days. So we built that mechanism, but then we onboarded our next cl- customer, and then they had 10 billion rows for one table, and that took about... That would've taken, like, two and a half months. Like, okay, built this method. That works great. Then every single data source, we have to go in and, like, learn how to make them extremely efficient. So like for Postgres as an example, we're now, like, querying the underlying systems, like columns, to be able to grab that data fa- faster. So do it more at, like, IO speed rather than, like, through a SQL engine. That's one. Another one is, like, we're now building out a SQL, a S- SQL Server connector, and why that's so hard is because change data capture through SQL Server the right way, as opposed to, like, doing it through what they recommend you, which is more or less backed by database triggers, is not very performant. No enterprises want to use that. So then to do it, quote-unquote, "the right way", you basically have to implement this backdoor method that's not documented.

    5. JC

      And I would say, like, even going on the customer side, as we, with each customer we learn something new, because everyone has messy data. But the messy data always looks different.

    6. RT

      [laughs]

    7. JC

      And then there's different scales of data. There are people with single-tenant database designs because they came, like it was, it was on-prem databases, and now you have 20,000, 30,000 databases that you need to ingest and merge into one table or some unified tables into the data warehouse, 'cause that's how you wanna do analytics. How do you d- make a one-click solution for stuff like that? Or you're sharding your database because you're growing so fast as a company, and then you're sharding it again. Those are things that tend to break, like, ordering guarantees or, like, schema evolution tends to break down. Um, fixing all of that and making sure the product still works under those, like, weird situations.

  13. 20:53 – 22:19

    Owning the whole stack: Kafka SDK ordering bugs and customer expectations

    1. RT

      Yeah. Another example that I have is, like, so we use Kafka, and like one thing that we also found out through Kafka was, like, we spent a year debugging this one problem. Basically, like, when Kafka goes, gets overwhelmed, sometimes it rebalances some consumers. So then, like, you basically have to reestablish your connections. We found the library that we were using, the SDK, had an ordering problem when it comes to rebalancing. So then as a result, like we're publishing the messages just fine, but then when we're reading it, sometimes it's reading it out of order. So then the data now is wrong on the destination. We found that on the consumer side and on the publishing side. And then what we then had to do is, like, debug the actual SDK to find out that, like, they weren't implementing, like, the Kafka Improvement Plan, like KIP, correctly. So then we have to switch vendors. Like, and it's like, just little things like that that's like, it's pretty... It, it becomes pretty gnarly.

    2. JF

      So the Kafka SDK library that you were using had its own bug.

    3. RT

      Yep.

    4. JF

      And I think this is actually an interesting, like, from the standpoint of your customers, they don't care-

    5. RT

      Yeah. [laughs]

    6. JF

      ... that the problem is in some, like, Kafka S-

    7. RT

      Yeah

    8. JF

      ... SDK library. Like, their bug is your bug.

    9. RT

      Yeah.

    10. JF

      And so, like, y- like, you, you end up having to, like, take responsibility for the whole thing.

    11. RT

      Yeah.

    12. JF

      Yeah.

    13. JC

      Yeah.

    14. RT

      They might b- they might be like, "Okay, I understand." But like, "Okay, what's next?"

    15. JF

      [laughs] Exactly.

    16. JC

      Or, like, even if, you know, um, a customer accidentally shoots themselves in the foot, that's technically still your problem.

    17. RT

      Your problem, yeah.

    18. JC

      Because where are the guardrails?

    19. RT

      Yeah.

    20. JC

      Like, why didn't you prevent that from happening in the first place?

    21. RT

      Yeah, totally.

  14. 22:19 – 23:16

    Where Artie is now: 700B+ rows processed and scaling toward trillions

    1. JF

      Okay, so we talked a bit about the early days. I wanna wrap up by talking about where Artie is now.

    2. RT

      Mm-hmm.

    3. JF

      Can you talk a bit about, like, what, what the current customers are like, what the current business is like, what's the scale you guys are operating at?

    4. JC

      Yeah. So it's, it's really exciting. We talked about some of, like, we started off with Substack doing a couple billion rows a month. Over the last 12 months, we've now processed over 700 billion rows of data, and that's up almost, like, 12X from the year before.

    5. JF

      Okay.

    6. JC

      Um, and so as we look into the future, it's really... And, and, you know, with more companies really looking at real-time data as important to deploy, like AI workloads, agentic AI use cases, um, we are really looking to increase the reliability, the scalability as we go from 700 billion to trillions of rows processed, um, and, and growing the team to make that happen.

  15. 23:16 – 24:23

    Team growth plan and founder advice: move fast, don’t overthink

    1. JF

      How much are you growing the team?

    2. JC

      We are going to triple the team, uh, this year.

    3. JF

      Oh, triple the team this year.

    4. JC

      If everything goes well, yes.

    5. JF

      Wow. Amazing. What kind of people are you hiring?

    6. JC

      Engineering, sales, marketing, operations, um, sales engineers, an in-house recruiter to help us-

    7. JF

      [laughs]

    8. RT

      Yeah

    9. JC

      ... hire all the... Actually, the most important is an in-house recruiter-

    10. JF

      [laughs]

    11. JC

      ... to help us hit our hiring goals, 'cause it's not happening without them.

    12. RT

      Yeah.

    13. JF

      Yeah. So guys, is there any advice that you would like to pass on to the next generation of founders?

    14. JC

      I would say my biggest advice is not to think too much or overthink something. And, you know, either you sh- take the YC advice, just try it. It may not always work, but at least-You just do it. You can observe what's happening and then make tweaks that way instead of staying stuck, um, trying to think if this is, like, the best path forward. Sometimes just at some point you stop discussing, just, just go do it, and, mm, that can help learnings a lot faster.

  16. 24:23 – 26:32

    Roadmap: beyond CDC into events APIs and new real-time destinations

    1. JF

      Yeah. Can you guys talk a bit about, like, the, the product roadmap, the plans for 2026? You're kicking off by announcing your Series A in January, but you've got a big year ahead of you.

    2. JC

      Yeah. I'll talk about the high level, and feel free to jump in, but, uh, when we started, we started with CDC, with databases. Part of the reason is the back- Robin's background, but part of it is, like, databases tend to be the, one of the highest volumes, one of the most complex, and it's your production data. Um, there is just a n- real-time need to have access to your production data. As we look into the future, um, we have launched an events API to get event data through s- some similar process streamed into Snowflake, Databricks, Redshift, um, and then expanding into a lot more sources and destinations where real time matters.

    3. RT

      Just to give you a couple examples. So the, the idea, the value prop of events API is, like, you hit this events API, within one to 200 milliseconds, you can query in Snowflake. And the reason why we're building this also is because the Snowflakes, Databricks, and Redshifts of the world, they're all starting to launch their own streaming APIs as well that are all relatively new. Like, Snowflake streaming f- just came out not that long ago. Same with BigQuery storage writer API. So, like, this is all just in perfect time for us to be able to build something where, like, instead of having you, you know, write this data to a destination and then wait a couple hours for this warehouse syncing job to run, we're just doing, literally doing 100 milliseconds. Another example is, like, we're thinking about building destinations that, such as, like, Elasticsearch, where, like, you want to be able to ingest up- an update from a Postgres so that you can index it correctly for search. Again, it's just, like, a- another-

    4. JF

      Yeah

    5. RT

      ... another thing that makes a lot of sense given the real-time nature.

    6. JF

      Yeah. Well, amazing, guys. Congratulations on the Series A and on hitting 700 billion rows. [laughs] That's pretty crazy. Uh, thank you guys so much for, for, for joining us.

    7. JC

      Yeah.

    8. RT

      Thank you.

    9. JC

      Of course. Thank you. [outro music]

Episode duration: 26:33

Install uListen for AI-powered chat & search across the full episode — Get Full Transcript

Transcript of episode M57MeOY-n3g

Get more out of YouTube videos.

High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.

iOSAndroidClaudeChrome