By playing, you agree to uListen's Terms and Privacy Policy and YouTube's Terms of Service.
YC Root AccessArtie: Real Time Data Streaming For The AI Age
Summaries, chapters, transcripts, and FAQs on this page are made by uListen, not YouTube.
Transcript
25 min read · 5,022 wordsIntro
Jared Friedman 0:00 [upbeat music]
Artie overview and Series A announcement
Jared Friedman 0:05 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.
Jacqueline Cheong 0:15 Yeah.
Robin Tang 0:15 Thank you.
Jacqueline Cheong 0:16 Thanks so much.
Jared Friedman 0:16 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?
Jacqueline Cheong 0:22 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.
Jared Friedman 0:50 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.
Origin story: the persistent pain of “data isn’t fresh enough”
Robin Tang 1:00 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
Why building CDC connectors in-house is a trap (and why Artie had to exist)
Robin Tang 2:00 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.
Jared Friedman 2:29 Yeah. It seems like not anyone's else's core competency.
Robin Tang 2:31 Exactly.
Jared Friedman 2:32 Like, you should be focused on your product, not m- not building, like, a weird data connector.
Robin Tang 2:36 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.
Jared Friedman 2:44 What are the companies where you saw this problem?
Robin Tang 2:46 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.
Jared Friedman 3:10 When you tried to build this before Artie at-
Robin Tang 3:12 Mm-hmm
Jared Friedman 3:12 ... these previous companies, engineers spent, like, a whole year-
Robin Tang 3:16 Mm-hmm
Jared Friedman 3:16 ... trying to build this and, like, failed to build it.
Robin Tang 3:18 Mm-hmm.
Jared Friedman 3:20 How long did it take you to build it at, like, at, at, as Artie? [laughs]
Early build timeline and YC-era “fake it till self-serve” onboarding
Robin Tang 3:24 Okay. Before AI got good, we w-
Jared Friedman 3:27 [laughs]
Robin Tang 3:27 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.
Jared Friedman 3:35 Wow.
Robin Tang 3:35 But did take six months because it was, it is a hard problem.
Jared Friedman 3:38 Yeah.
Robin Tang 3:38 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.
Jared Friedman 3:49 Yeah.
Robin Tang 3:49 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-
Jared Friedman 4:12 Yeah. [laughs]
Robin Tang 4:13 Yeah. It took us, like, probably almost 10 months to fully make this product self-serve.
What existed at YC application time: infrastructure first, sales skills later
Jared Friedman 4:17 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?
Robin Tang 4:25 Yeah.
Jacqueline Cheong 4:25 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.
Jared Friedman 4:49 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.
Jacqueline Cheong 5:04 Mm-hmm.
Jared Friedman 5:04 And so, like, has to be reliable from the get-go. And also, I assume really small companies don't have this problem, right?
Jacqueline Cheong 5:11 That's correct.
Jared Friedman 5:11 So, like, the only people who have this problem are, like, pretty big companies-
Jacqueline Cheong 5:15 Mm-hmm
Jared Friedman 5:15 ... 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.
Robin Tang 5:21 Yeah.
Jared Friedman 5:22 How did you guys get your first customer data?
Landing Substack: mission-critical first customer via cold email + POC
Jacqueline Cheong 5:23 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.
Jared Friedman 5:58 Yeah.
Jacqueline Cheong 5:58 So this is like, this happens to all our-
Jared Friedman 6:00 And this was your first deployment.
Jacqueline Cheong 6:01 Yes.
Jared Friedman 6:01 So like you had built this product that l- literally nobody was using.
Jacqueline Cheong 6:05 Yeah.
Jared Friedman 6:05 Substack has like millions of users.
Robin Tang 6:07 Yeah.
Jacqueline Cheong 6:07 Mm.
Jared Friedman 6:08 And they were considering deploying this thing in production-
Jacqueline Cheong 6:11 Yeah
Jared Friedman 6:11 ... for their millions of users that no one had ever used before.
Jacqueline Cheong 6:13 Yes.
Jared Friedman 6:14 Okay.
Jacqueline Cheong 6:15 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-
Jared Friedman 6:38 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?
Jacqueline Cheong 6:45 Yeah.
Robin Tang 6:45 Or something like that, right.
Jacqueline Cheong 6:46 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.
Jared Friedman 7:55 And how did you get in touch with them?
Jacqueline Cheong 7:58 It was a cold email.
Jared Friedman 7:59 It was a cold email.
Jacqueline Cheong 7:59 It was a cold email.
Jared Friedman 8:00 Wow. So-
Jacqueline Cheong 8:01 And this was when we were very bad at writing cold emails. [laughs]
Jared Friedman 8:05 [laughs] But I guess just the need was so great that they just went with it anyway.
Jacqueline Cheong 8:11 It was-
Jared Friedman 8:11 If you were just making something that they really needed.
Jacqueline Cheong 8:13 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?"
Jared Friedman 8:26 Hmm.
Jacqueline Cheong 8:26 It was Friday. Uh, we chatted in the afternoon, and, and he was like, "Okay, great. Um, when can we try the product?" And so we-
Jared Friedman 8:34 Wow
Jacqueline Cheong 8:35 ... spent the like next two days trying to build as much into the UI as possible so they could actually like see something outside of the infrastructure, and starting the next Monday went ahead and deployed.
Why growth is lumpy for infra: long gaps between ‘big bets’
Jared Friedman 8:47 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-
Jacqueline Cheong 8:57 No
Jared Friedman 8:57 ... or easily.
Robin Tang 8:58 Mm-hmm.
Jared Friedman 8:58 'Cause every one of these customers is like Substack.
Robin Tang 9:01 Yeah.
Jared Friedman 9:01 They have to make a really big bet on you guys that you're gonna run a foundational piece of their infrastructure.
Robin Tang 9:06 Yeah.
Jared Friedman 9:06 What were the first six months of YC like?
Jacqueline Cheong 9:09 It was pretty slow. Um, I mean, we did manage to get, during YC, about like seven or eight customers.
Jared Friedman 9:16 Okay.
Jacqueline Cheong 9:17 Um, and most of them were smaller, uh, more like early adopters. But, um-
Jared Friedman 9:23 Substack, if I remember correctly, was really the first big customer that took-
Robin Tang 9:27 Yes
Jared Friedman 9:27 ... a bet on you for like a long time.
Jacqueline Cheong 9:28 Yes.
Robin Tang 9:29 Yes.
Jared Friedman 9:29 Like that one came really quickly-
Jacqueline Cheong 9:31 Yes
Jared Friedman 9:31 ... right off that cold email, but then it took... How long did it take before you got another Substack scale customer?
Jacqueline Cheong 9:36 It probably took another nine months-
Robin Tang 9:39 Yeah
Jacqueline Cheong 9:39 ... before we had another one.
Jared Friedman 9:42 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.
Robin Tang 9:47 Oh.
Jacqueline Cheong 9:47 Really?
Jared Friedman 9:47 Where their, their very first customer of Substack was this really famous blogger.
Robin Tang 9:53 Mm-hmm.
Jared Friedman 9:54 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.
Jacqueline Cheong 10:07 [laughs]
Jared Friedman 10:08 And then like during the batch, they did not close any other big customers, and it actually wasn't until over a year into the company that they closed a second customer comparable to the first one.
Robin Tang 10:18 Yeah.
Reaching $1M ARR with a tiny team: disciplined hiring and founder-led sales
Jared Friedman 10:18 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.
Jacqueline Cheong 10:28 Mm-hmm.
Jared Friedman 10:29 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.
Robin Tang 10:41 They were doing about one to two billion during the batch per month.
Jared Friedman 10:43 Yeah, like one to two billion rows of data.
Robin Tang 10:46 Yeah.
Jared Friedman 10:46 It was just the two of you working on this, right?
Jacqueline Cheong 10:49 Mm-hmm.
Jared Friedman 10:51 [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?
Jacqueline Cheong 11:10 Uh, it was the two of us and two engineers.
Jared Friedman 11:13 At a million ARR?
Jacqueline Cheong 11:14 Mm-hmm.
Jared Friedman 11:15 That's pretty crazy. W- how do you guys explain that? Like what did you do that made that possible?
Jacqueline Cheong 11:22 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-
Robin Tang 11:56 [laughs]
Jacqueline Cheong 11:56 ... 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.
Robin Tang 12:52 Yeah.
Jared Friedman 12:52 'Cause during the batch, you were just building the product-
Robin Tang 12:55 Mm-hmm
Jared Friedman 12:55 ... and you were just selling the product-
Robin Tang 12:57 Yeah
Jared Friedman 12:57 ... and that's all there was.
Jacqueline Cheong 12:59 Yep.
Robin Tang 12:59 [laughs]
Jacqueline Cheong 13:00 I was basically a very good SDR-
Jared Friedman 13:02 [laughs]
Jacqueline Cheong 13:03 ... for the first year, year and a half of the company.
Robin Tang 13:07 Yeah. We're a Venn diagram that doesn't intersect. [laughs]
Jared Friedman 13:12 [laughs]
Married co-founders: deciding to jump in and how it changes the work dynamic
Jared Friedman 13:12 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.
Robin Tang 13:19 Yeah.
Jacqueline Cheong 13:19 Yeah.
Jared Friedman 13:19 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-
Jacqueline Cheong 13:26 Yeah
Jared Friedman 13:26 ... was it, was it, was it something you guys were worried about i- i- initially?
Jacqueline Cheong 13:31 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."
Jared Friedman 14:02 Mm-hmm.
Jacqueline Cheong 14:02 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.
Jared Friedman 14:10 Mm.
Jacqueline Cheong 14:10 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.
Jared Friedman 14:32 Mm-hmm.
Jacqueline Cheong 14:33 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-
Jared Friedman 14:45 Mm-hmm
Jacqueline Cheong 14:46 ... 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-
Jared Friedman 14:54 You guys both had jobs, right? You, you-
Jacqueline Cheong 14:56 Yeah
Jared Friedman 14:56 ... y- you both quit your jobs to do this.
Jacqueline Cheong 14:58 Yep.
Jared Friedman 14:58 Yeah.
Jacqueline Cheong 14:58 Yep, we quit at the same time.
Robin Tang 15:00 [laughs]
Jacqueline Cheong 15:00 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."
Jared Friedman 15:08 [laughs]
Jacqueline Cheong 15:09 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.
Jared Friedman 15:23 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-
Jacqueline Cheong 15:31 [laughs]
Jared Friedman 15:31 ... before you decided to also be, be co-founders.
Jacqueline Cheong 15:34 Yeah.
Jared Friedman 15:34 How has it changed your relationship and your lives?
Jacqueline Cheong 15:38 I would say it's actually brought us a lot, lot m- closer. Um, having a deeper understanding of how we think about problems, 'cause they're very different. Um, one interesting thing is we usually at, land at the same outcome, but the path to get there, the way we think is just completely different.
Jared Friedman 15:59 Mm.
Jacqueline Cheong 15:59 I will say what has been very helpful is feedback cycles.
Jared Friedman 16:05 Hm.
Jacqueline Cheong 16:06 Um, I'm su- like, because we are married, um, there is a layer of filter that is naturally removed.
Jared Friedman 16:16 Mm.
Jacqueline Cheong 16:16 You know, when you're frustrated with your co-founder, when there's something that doesn't feel quite right but it's not that serious yet-
Jared Friedman 16:24 Mm-hmm
Jacqueline Cheong 16:24 ... I think there's an, there's an inclination to keep it in.
Jared Friedman 16:28 Mm.
Jacqueline Cheong 16:29 With us, every little thing-
Jared Friedman 16:31 [laughs]
Jacqueline Cheong 16:31 ... every little thing, an inkling of a thought, gets discussed.
Jared Friedman 16:35 Yeah.
Jacqueline Cheong 16:35 Um, and I think because of that, there's nothing that's like pulling the company back at any point in time. Like, and we can... Again, I think it's just the moving faster part. We can talk about things faster and move a lot faster.
Work-life boundaries (or lack thereof) when building high-stakes infra
Jared Friedman 16:49 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?
Jacqueline Cheong 17:03 We have had discussions about it, and we've decided it's not a good move. [laughs]
Jared Friedman 17:09 [laughs]
Robin Tang 17:09 [laughs]
Jacqueline Cheong 17:09 I don't think we have a life outside of Artie at the moment. [laughs]
Robin Tang 17:13 It's hard. [laughs]
Jacqueline Cheong 17:14 There, there would be nothing else to talk about. [laughs]
Robin Tang 17:17 [laughs] Yeah.
Jared Friedman 17:18 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.
Robin Tang 17:26 Yeah.
Jared Friedman 17:26 This is really hard to build.
Robin Tang 17:27 Yeah.
Battle scars of real-time data: backfills, edge cases, and undocumented ‘right ways’
Jared Friedman 17:27 Do you wanna talk at all about... I don't know. Are any of those interesting to talk about?
Robin Tang 17:32 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]
Jacqueline Cheong 18:16 [laughs]
Robin Tang 18:16 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.
Jacqueline Cheong 19:54 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.
Robin Tang 20:08 [laughs]
Jacqueline Cheong 20:08 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.
Owning the whole stack: Kafka SDK ordering bugs and customer expectations
Robin Tang 20:53 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.
Jared Friedman 21:41 So the Kafka SDK library that you were using had its own bug.
Robin Tang 21:45 Yep.
Jared Friedman 21:46 And I think this is actually an interesting, like, from the standpoint of your customers, they don't care-
Robin Tang 21:52 Yeah. [laughs]
Jared Friedman 21:52 ... that the problem is in some, like, Kafka S-
Robin Tang 21:54 Yeah
Jared Friedman 21:54 ... SDK library. Like, their bug is your bug.
Robin Tang 21:56 Yeah.
Jared Friedman 21:57 And so, like, y- like, you, you end up having to, like, take responsibility for the whole thing.
Robin Tang 22:00 Yeah.
Jared Friedman 22:01 Yeah.
Jacqueline Cheong 22:01 Yeah.
Robin Tang 22:01 They might b- they might be like, "Okay, I understand." But like, "Okay, what's next?"
Jared Friedman 22:04 [laughs] Exactly.
Jacqueline Cheong 22:06 Or, like, even if, you know, um, a customer accidentally shoots themselves in the foot, that's technically still your problem.
Robin Tang 22:14 Your problem, yeah.
Jacqueline Cheong 22:14 Because where are the guardrails?
Robin Tang 22:16 Yeah.
Jacqueline Cheong 22:16 Like, why didn't you prevent that from happening in the first place?
Robin Tang 22:19 Yeah, totally.
Where Artie is now: 700B+ rows processed and scaling toward trillions
Jared Friedman 22:19 Okay, so we talked a bit about the early days. I wanna wrap up by talking about where Artie is now.
Robin Tang 22:24 Mm-hmm.
Jared Friedman 22:25 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?
Jacqueline Cheong 22:30 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.
Jared Friedman 22:47 Okay.
Jacqueline Cheong 22:48 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.
Team growth plan and founder advice: move fast, don’t overthink
Jared Friedman 23:16 How much are you growing the team?
Jacqueline Cheong 23:18 We are going to triple the team, uh, this year.
Jared Friedman 23:21 Oh, triple the team this year.
Jacqueline Cheong 23:22 If everything goes well, yes.
Jared Friedman 23:23 Wow. Amazing. What kind of people are you hiring?
Jacqueline Cheong 23:26 Engineering, sales, marketing, operations, um, sales engineers, an in-house recruiter to help us-
Jared Friedman 23:37 [laughs]
Robin Tang 23:38 Yeah
Jacqueline Cheong 23:38 ... hire all the... Actually, the most important is an in-house recruiter-
Jared Friedman 23:40 [laughs]
Jacqueline Cheong 23:41 ... to help us hit our hiring goals, 'cause it's not happening without them.
Robin Tang 23:44 Yeah.
Jared Friedman 23:44 Yeah. So guys, is there any advice that you would like to pass on to the next generation of founders?
Jacqueline Cheong 23:51 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.
Roadmap: beyond CDC into events APIs and new real-time destinations
Jared Friedman 24:23 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.
Jacqueline Cheong 24:33 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.
Robin Tang 25:19 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-
Jared Friedman 26:11 Yeah
Robin Tang 26:11 ... another thing that makes a lot of sense given the real-time nature.
Jared Friedman 26:14 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.
Jacqueline Cheong 26:24 Yeah.
Robin Tang 26:24 Thank you.
Jacqueline Cheong 26:24 Of course. Thank you. [outro music]
Episode duration: 26:33
In the uListen app, the transcript lights up word by word as you listen. Get uListen
Transcript of episode M57MeOY-n3g