0:00All right. Hey, everybody. Good to see you here. I'm super, super pumped as we talk about Postgres CDC with Streamkap today. I am Jacob. I work on the DevRel team at MotherDuck. I'm going to throw it to Paul real quick. Paul, why don't you say hi to the crew here?
0:23Hi, everybody. And yeah, thanks for having me on, Jacob. I'm Paul Dudley. I'm one of the co-founders of Streamkap. Amazing. Amazing. Thank you, Paul. And before we get into kind of the meat of this, just as a reminder for everybody, I'm just going to talk briefly about what MotherDuck is.
0:43So MotherDuck is a cloud data warehouse that is built on top of DuckDB. And one thing that we're really seeing at the moment that's really cool and fortuitous for us. So we built a data warehouse that gives every user their own database, their own compute engine, which is really cool. And as it turns out, this is great for agents because maybe some of you saw this going viral on Twitter a couple of days ago.
1:06Someone was able to delete their database with Codex, with GPT 5. 6 Sol, which is this new model, so-called smart model. MotherDuck's isolation levels make sure that that can't really ever happen. We also have snapshotting and time travel so you can avoid things like that, too, which is great.
1:27But the point really here is that the architecture scales really nicely because AI queries differently than humans do. And if you're using something like Postgres, it can be very challenging to get this all working well, which means you need to introduce things like CDC, like we're talking about, on top of your Postgres and go from there.
1:50If you don't know what DuckDB is, I'll just talk about it quickly. It's a lightweight, embeddable database. You can run it locally. It's super fast. Everything scales out vertically. It uses this really cool technology called Morsel-Driven Parallelism, and that means that your entire CPU is used. And, you know, now we all have machines with 16 cores.
2:11That's a lot of work that we can do on the database. And then what MotherDuck is doing is wrapping all these really nice things. It's all serverless. We have hypertenancy, which means, again, like I was talking about, we have these isolated compute units across users, and then really nicely ties in with agents. There's an MCP server. There's dives and flights.
2:35And this means that all of these pieces you can interact with and make it all just really work nicely from your agent and really don't think about your database at all. I think that really ties in nicely to stuff that Paul is building in Streamkap, so I'm going to throw it over there to him now and take my slides off.
2:58Great. Thank you, Jacob. Maybe I've not been paying enough attention, but it's the first time I've heard Morsel-Driven Parallelism. It's sort of a fun term. But, yeah, Streamkap, we're a platform for streaming ETL and change data capture.
3:21Most of the work we do is database replication. We can get data from your databases in real time. And we'll talk a little bit more about some of the nuances of CDC in a minute, so I won't go too much into detail, but basically we get data out of your databases, get it into your OLAP, things like MotherDuck.
3:45And under the hood, we use Kafka and Flink. But one of the advantages that we offer is you get all the power of those things, but you don't have to think about managing them. At the simplest level, you're just plugging in the credentials for your source database and for your destination. Data gets from A to B in a sub-second, and it's very reliable and cost-effective.
4:08You'll see a lot of folks who bring workloads over from batch ETL tools like Fivetran, and they get faster, cheaper, and more reliable replication. We work with a bunch of leading companies to help them power better customer-facing use cases, better internal operational use cases where they need low latency.
4:32And in some cases, they just want a more reliable and cheaper way to do things. And the speed is sort of an ancillary benefit. And, you know, one of the ways that I guess a few of our customers have told us that they really appreciate Streamkap is, you know, they're not getting paged anymore, right?
4:52So if you've been on the pager before, you know that can be pretty painful. And we build very reliable systems that don't fail very often. I won't say it never fails. And that, you know, our team is actually proactively monitoring your pipeline. So if you have a production pipeline in Streamkap, we get paged first,
5:14and we're looking into it proactively for you. So that's always something that folks appreciate. And, yeah, I think that's sort of the high level on Streamkap. But what we thought we would do is we'll actually go through a demo here. But before we dig into the details, maybe just talk a little bit about what Change Data Capture is and, you know, why you would use it.
5:37So, you know, I think we're obviously focusing in particular on Postgres here today. Postgres is a great database. You know, it's very capable. It can do a lot. There's a lot of amazing extensions. And so kind of the first recommendation we have is use Postgres for as long as you can, right? So, you know, a lot of companies or projects as they're starting out, you know, you choose Postgres,
5:59particularly now in these agentic era, choose Postgres first. And, you know, that's how you're starting out. And, you know, basically, as you start to scale, maybe you start to think about having a replica for doing some of your, you know, your analytical queries. You might do indexing. You might do materialized views.
6:22But at some point, Postgres is ultimately a transactional database. It's row-based. And so there are going to be analytical queries where you're, you know, looking across rows where Postgres just isn't the right choice and you're going to run into performance problems, cost problems, and you need to offload that data to a more suitable database like MotherDuck
6:44that's column-oriented and very fast for analytical queries. And that's really where change data capture comes in. I think technically there's a lot of definitions, but usually when people are talking about CDC, they're talking about log-based CDC. So that's reading the change log of a database.
7:06So all the updates and deletes and inserts that are happening in that database get recorded to a log. And then you're reading from that log all of those events and replicating that into another database. So that's kind of the essence of CDC. The advantages of that is that it's, you know, that log is already being created,
7:29so you're reading from a source that doesn't put any load on the database in contrast to, let's say, doing a nightly snapshot of your database and replicating it all at once. It also has the advantage that it captures all of the changes that are happening over the course of the day in that case. So, you know, if you do a nightly snapshot, you know,
7:51sometimes that can cause challenges with capturing deletes, for example, because they're no longer in the database. So change data capture has a lot of advantages and, you know, can be a really great way to get data out fast and with low load on your source database.
8:12So what we're going to do today is we're actually going to get data from Postgres into MotherDuck. So I've got a database that I've set up here. It's pretty simple. It's a Postgres database, and I've got a Paul webinar demo schema. We've got a heartbeat table, which we'll talk about a little bit later.
8:36And then we've got a payments table, which is our primary data here. So we've got a bunch of different elements, payment ID and customer email, payment provider, the amount and so on and so forth. So that's our database. We currently have.
8:58Sixty thousand rows in the database. I've got a little Python script here. That's going to populate data into into that database. Let me see. That's the wrong window.
9:21Sorry.
9:34OK, so. OK, there we go.
9:52So now we're writing transactions into this database on the order one of one second or so. So we're incrementing our little database up.
10:05We've got that set up and we have a MotherDuck database here with that Paul webinar demo schema, but nothing populated in it yet. We'll come back to MotherDuck in a little more detail. Then we've got Streamkap here.
10:24Streamkap, by the way, can be deployed as a SAS or bring your own cloud so it can be deployed in your local local Claude environment. Your data doesn't leave. In that case, this is in this example, our SAS user experience is going to be the same either way. We'll come look at the UI, but we're mostly going to use Claude to to deploy this.
10:45But right now I've got a couple of connectors that are set up. We support a bunch of different source databases, you know, kind of all your most popular relational and SQL databases, cloud storage. You can stream directly from Kafka. You can.
11:04We're increasingly supporting different kind of WebHook and CC sources outside of databases. With with more coming online over time. And then we've also support a bunch of destinations. So I have a few different set up here. I don't yet have MotherDuck set up again.
11:21We could set that up through the UI if we wanted to, but we'll go ahead and use Claude for that. Before we dig into Claude, though, I've already installed Streamkap's MCP server. It's actually available as a connector in Claude.
11:41So you can just connect through the connector library there. I've also installed the MotherDuck MCP server. And that's kind of the basics here. So here I've got my Claude session and I'm going to say let's watch me type.
12:03We've got a prompt build here. Basically, I want to say I'm pulling from this Postgres source and putting that into MotherDuck. So we'll give that a few minutes. But while we're doing that, we kind of dive one level deeper into Postgres.
12:24Everyone I've spoken to spent much time doing CDC from Postgres has the experience of taking down their production database because of the wall log. So maybe we'll talk a little bit about that. Basically, the wall log, I guess saying wall log is a little bit like saying ATM machine. But anyway, I still find myself doing it.
12:47And what the wall is, the write ahead log, basically for a Postgres cluster, all of the traffic through that cluster gets written to the write ahead log.
12:59And then when you set up CDC, what you're doing is you're creating a replication slot that says, hey, hold on to that log data until I have read the elements of it that I want to capture for change data capture.
13:14And particularly before Postgres version 16, that could be a bit of a problem, because if you weren't careful about setting up the monitoring that we highlight here in this section of our docs.
13:28And for example, you lost your connection to that replication slot, then you weren't sending a signal to Postgres that you had read the log. And therefore it was keeping it because you told it you wanted to keep that log data until you'd read it. And so you lose that connection.
13:47Your storage that is allocated for the wall log fills up and you could take down your database. And again, before version 16, you could only set up logical replication on the primary, which meant that if that happened, you just took down your production database.
14:07So even if you're still on versions before 16, this is not something you can't deal with. You can manage these risks by having appropriate monitoring, having the appropriate growth to allowing enough space in your storage for your log to grow. We recommend at least three days.
14:31That way, if something happens over the weekend, you're not scrambling to fix it while the weekend's happening and worrying about database issues. But anyway, I won't go through all the details, but basically having good monitoring, having sufficient storage for the wall log and auto growth and things like that will take care of you.
14:56The other dimension is there's a couple of scenarios where you can have that scenario. One is if you lose your connection to the database, so you're not able to read it. Another is if you have a low traffic database, so your wall is capturing everything in that cluster. But your replication slot could just be reading a few tables from it.
15:13And if you're only reading low traffic tables, the background of all the wall could be getting very large while there's very little traffic coming through. So, again, you're not sending a signal in to the database to say that you've read it. We'll come back to that concept with heartbeats when next time we jump in the Claude. But let's see how Claude is doing.
15:35And it looks like we have things live. So let's check into Mother Duck. And sure enough, now we've got two tables in our schema, RP and payments. We can check.
15:56Now we've got 62,000 rows in that payment table. So we've connected into the source. We've completed a snapshot. So all of the data that's there and now we're streaming that data ongoing. And you can see we've got 62,000, 66, 70 and so on. So we're incrementing more data coming in.
16:20We can also see the rows in this table, the columns we have here. So it's all the stuff we had on the source side. And there's some Streamkap metadata that gets added here as well. So I'm sure a lot of folks on the call here would be more than capable of exploring this data with SQL.
16:44But one of the things we're going to do is take advantage of Mother Duck's new dives here and create some visualization of this data right here in Mother Duck. So let's go back to Claude and kick that off.
17:05I've asked Claude here to do a couple of dives. One, reporting for the payments and then the other, just a latency report. While we're waiting on that, we can take a look at Streamkap here.
17:29So now you can see we've got our webinar payments demo Postgres source set up. And if we click into that, we can see our source latency, 117 milliseconds. We can see our snapshots are completed.
17:47If I want to run another snapshot, let's say something goes wrong or I'm adding a new table, it's very easy to do that. You can do it at the table level, across your tables, schemas, databases. And this is actually one of the things that our customers really like about Streamkap, is we have a lot of flexibility within snapshots. So we can do a filtered snapshot.
18:12Where do those save? Where are you saving those? Where are the snapshots saved? Are those going into Streamkap? Are they going into Postgres somewhere? I'll ask you a question. So it's different from, I think, the concept of snapshots as you would think about it in MotherDuck. So what this is doing is, this is doing a snapshot of the source and then writing it into the destination.
18:36So we just did a snapshot when we started because if I just started streaming, I would get the new change events, but I wouldn't have the 62,000 original rows. So I need to do a snapshot to get those 62,000 original rows. So most of the time, folks are doing a snapshot once and then they're just getting new information coming into the stream.
18:58But things happen. Sometimes you might need to add a new table. You might lose connection to the source database. You might be doing migration. That meant you need to do a snapshot again. And so that's where this comes back into play outside of the initial setup. So the filtered snapshot is a relatively recent feature, but that allows you to do a SQL statement.
19:19So let's say you lost connection to the database and you lost a day's worth of data. A lot of tools, you have to go and re-snapshot the entire table. And that can be a problem if it's a big table, billions of rows. It just takes time and puts load on things. But the filter snapshot allows you to say, well, we actually only lost a day's worth of data. Let's go and snapshot that. And then we have different options for capturing all the data.
19:41Full snapshot is a pretty low, a low load, low risk approach that moves pretty slow. But that's usually suitable for your first time setup where there's not a lot of criticality around the time. Blocking snapshot is another version of that. And then we have different options for capturing all the data. And then we have different options for capturing all the data. that captures the entire full snapshot.
20:03It's incremental, so it goes chunk-wise through your tables. Blocking snapshot captures an entire table at a time. So it can go faster, but can't be resumed. And then we have another new functionality, which is a fast parallel snapshot, which goes really fast. So you can do tens of billions of rows in a few hours with the fast parallel snapshot. So that's the kind of thing where we see
20:26with some customers who have operational scenarios where they end up having to do snapshots on a semi-recurring basis. So they need to know that they can get all of that data repopulated really quickly. And that's been really popular among those folks. So those are some of the basics. Yeah, that's awesome. Yeah, okay. I mean, obviously, like you alluded to it earlier, sometimes you have issues or there's a new table
20:50and you need to do a rapid backfill. This is a nice abstraction. Really cool. Thanks, yeah. It's the kind of thing that you maybe don't think about it until it comes up. And then you're like, boy, this is really painful. And we had somebody who was telling us they have like a 50 billion row table and with their batch ETL provider, it takes them three weeks to backfill it.
21:15And so, yeah, that's a pretty big deal if you've got a critical table that takes you three weeks to get it back up to speed in your data warehouse. Yeah, no kidding. Whereas with us, that would take like 10 or 12 hours. So yeah, sometimes when the rubber hits the road, that's where things get really, where you kind of differentiate on this stuff.
21:39It doesn't sound quite as exciting as it might otherwise. Yeah, that's a critical aspect. That's on the source side. Destination's pretty straightforward. We've already got our MotherDuck connection set up here. And then what Quad did for us was set up the source, set up the destination, and then it set up a pipeline. And we can see we're getting our end-to-end latency of about a little over half a second at this point.
22:05That's the basics. And the other point I'll make just on the Streamkap, the platform's pretty straightforward in terms of how it works. We can also do alerting. So you can plug this into your, whatever monitoring systems, whether you just want a Slack channel or email, but also you can go into your Grafana, Splunk, Jadadog, what have you,
22:26and get your alerting wherever you need it. But let's check on how Claude has done with something a little more exciting than just looking at SQL. So we see now Claude's created a couple of dives for us. And one is our payments dashboard. We've got this updating every two seconds
22:50and giving kind of a 15-minute look back on what our revenue is, our payment success rate, number of failed payments, what have you. And let's add a little color to this. So my Python program,
23:15I can trigger a increase in our Stripe failure rate. So we can see what happens. Our payments team is monitoring their payments dive here. And I'm actually not sure, probably wanna look at checkout. com. We had an issue there as well.
23:38But we can see that our Stripe failure rate is increasing pretty rapidly here. And so as is checkout, interesting. I don't recall having put the checkout into my scripts, but maybe it's just less reliable in my Python altogether.
24:03So, right, but it's pretty cool. Like we were able to, Quad was able to put this together for us in just a couple minutes. And we've got a good way to view kind of real-time data coming into MotherDuck. Yeah, that's super cool. And we might also say,
24:26well, there's something going on here, right? So we might wanna go and do a little bit of a deeper dive, having seen that the failure rate is increasing. So I'm gonna ask Claude to do a new dive to understand what's happening with that Stripe failure.
24:52Yeah, I love, you know, I think like one thing that's really cool about dives is like a lot of the analysis we're doing on this type of work is like disposable, right? And so like it finally matches the paradigm of disposable analytics to, you know, prompt or prompting and the data. And it's like, look, if you make a really good one, maybe you wanna keep it. But in general, it's like, hey, something happened in this window.
25:16What the heck went on? I need to figure, I need to know it quickly. I don't need to keep it forever, right? And so I think like that's a really nice tie-in, you know, operationally to like everything else that's going on. And I think really, really resonates with me. And then, you know, obviously I can do a lot of, a lot of really, I can do more, even more analytics because more of them are disposable, right? Anyway.
25:40Yeah, I should have asked Claude to look at this checkout thing, because like I said, that's somewhat surprising. It went to a hundred percent failure rate. So maybe that's some Claude non-determinism in my- Yeah, Claude also looked at my Python scripts. Yeah. Yeah, exactly. But let's see. We're still working away on that.
26:03But while we're waiting for that second level, we can talk about, I mentioned that, you know, one scenario where folks can run into trouble with the wall log is with low traffic databases. And basically, you know, again, what can happen there is the walls like is across the whole cluster and there's high activity databases,
26:25but you only subscribe to one that has very low traffic. And so you're, you know, you're only getting pings when new records come into your low traffic databases. And, you know, if that's infrequent enough, the other traffic could fill up the database. So you have, by the way, we've got a bunch of great docs here. So, you know, I think if you're thinking about it, you can dig into all the FAQ here
26:49on what you want to look for. And, but for Heartbeats basically, for low traffic databases, Heartbeats become very important. It's basically like artificial traffic on your database. And there's a couple of levels. There's a connector Heartbeat, which emits a message internally to keep the connector alive if you have a low traffic database
27:11and just, you know, maintain its connectivity. And then we generally recommend a layer two Heartbeat, which is actually a table in your database where we're writing that artificial traffic and basically just sends a signal periodically
27:34that ensures that there's always gonna be traffic coming through your replication slot and prevents that scenario of a low traffic database allowing the wall log to accumulate and cause issues. So anyway, it's something we tend to recommend for folks and always good to think about if you're doing,
27:58it's actually relevant beyond Postgres as well. It's a good practice in a lot of CDC, but particularly Postgres with the wall log. So let's see if we've got a deeper dive here. So we've got our Stripe failure investigation. And we see that our provider, we had a timeout with one of our providers.
28:20It looks like that started at 9. 54. So we've got to go switch to another provider there. Yeah, yeah, okay. I mean, obviously we're controlling the knobs here, but nonetheless, it is very interesting that Claude can help us quickly do this stuff. I mean, I think a lot of this stuff is just like tying out the right scaffolding
28:42so that you can get the right answers quickly. And I think these are all the things that we really care about and really matter, especially if you're running payments on a Postgres database. This is super cool. Yeah, yeah, it's funny. Claude is, you know, he's getting more ambitious. So he did try, when I first did my little test run here, he did try to answer the question for me.
29:06And I was like, yeah, that's nice. I appreciate that the problem is the provider timeout, but I do actually want to see a dive as well. And one of the advantages there, of course, being that I can go and check with the dive. I can check what we actually, you know, what Claude built and ensure that I agree
29:29with his approach to getting to those answers. Yeah, totally, totally agree. Cool, well, that's what I had for y'all from a demo perspective. Perfect. And I'm sure we kick over to any questions folks have. Yeah, we've got some questions in the chat that I'm going to pull up.
29:57And we'll get rolling. So yeah, feel free, by the way, if you have questions, throw them in the chat. We'll get to them as we get to them here, you know, both from OtherDuck and Streamkap. First one here is Streamkap versus Apache Flink, similarities and differences. Yeah, so we've got a couple of different options Yeah, so we actually do use Flink under the hood. In this pipeline, we're not using it,
30:21but if you want to do stream processing, Streamkap has Flink in the platform. So if you go into our transform section, this is powered by Flink. And there's all kinds of different use cases that we see for that. So you can do transformations, enrichment, really anything you can do with Flink, but we've kind of flipped it around. I mean, Flink can be hard to use and hard to manage.
30:45And so what we've prioritized is, what are the patterns of uses that we see our customers engaging in? And then we kind of build you templates to layer on top of that. So that's been something that our customers have appreciated when they want to do streaming transformations. The way I like to think about it is, you know, if you think about like the two core underlying distributed systems that we use,
31:10Kafka and Flink, you know, they're both great, both very powerful, but pretty heavy to manage. And so, you know, with both of those, you kind of start from the ground up, you're making a big commitment to say, you know, we're going to build some event-driven architecture and streaming and stream processing. But it requires a lot of, you know, knowledge and engineering time and DevOps time.
31:34And Streamkap kind of flips that around. Like at the simplest level, you can just connect a source and a destination, and then you can expose more over time. You can use our Kafka, like you would use any other managed Kafka. You can use our Flink to do stream processing, but you're making a little bit less of a commitment of like how much of it you're going to manage yourself. And you can kind of expose the complexity and power as you need to, rather than making that commitment at the beginning.
32:00Yeah, that makes sense. And then we have one similar question here. What does it bring to the table compared to SRE-5-TRAN or good old Debezium slash Maxwell? I think you just answered the second question, you know, in terms of level of abstraction and ease of use. I'm curious what you think about it versus those two. Yeah, so I would also note on the, you know, we also use Debezium.
32:23We're built on top of Debezium. And, you know, going back to the snapshots that we talked about earlier, that's another thing we built all of that infrastructure. I mean, Debezium has some snapshotting capability, but that's often painful. And so a lot of that stuff is layered on top. And then, you know, 5-TRAN is probably the company that folks are most often migrating from. And, you know, generally for the reasons
32:48I mentioned earlier, faster, cheaper, better support, more reliable pipelines. But I will say they have a great library of API sources. So if you've got, you know, Google Analytics and, you know, Facebook ads that you need to sync, then, you know, 5-TRAN is definitely a good option. But the folks who are migrating generally are migrating CDC workloads to us. And then Asteroid is-
33:12Like databases, yeah. That's right. Yeah, exactly. Although stay tuned on that front. And then Asteroid is a little more similar to Streamkap. And so, you know, I think where we tend to see folks choose, again, kind of comes with, they also do APIs. You know, we see folks generally choose Streamkap
33:35in contexts where they have, you know, larger volumes, they need the snapshot power, they need the powerful transformations. We have folks who are doing, we've become, I guess, database experts. We didn't talk a ton about this, but like, you know, we have customers who have millions of source tables and we built a lot of capability in the platform to manage, you know, a lot of underlying database complexity
33:59and, you know, that's sort of better at a high level and one of the reasons folks choose us as well. That makes a ton of sense. Follow-up question from Paolo here. How does Streamkap deal with evolving schemas? Oh, that's a good question. I debated whether to put that into my demo, but I just said we didn't really have enough time. So we handle that elegantly.
34:20You have automated schema evolution. So basically, if you have a new column, we'll add the new column into the destination. If you remove a column, you know, we'll just leave it empty. If you have a change in the data type, we'll add a new column with the new data type. So it would be column name underscore data type.
34:45If it goes back, we'll go back to populating the old one and anyway, it won't go through all of it, but yeah, that's stuff that we handle automatically. Awesome. So like, okay, no, that makes no sense. Schema evolution definitely can be challenging, especially for your downStreamkonsumers. So I know you briefly touched on it
35:07and you used the MCP to set up the pipeline. How are you seeing, are you seeing customers, you know, beginning to use the Streamkap MCP, like kind of on a day-to-day basis? Yeah, we released it, I guess, a couple months ago and I wish I had better stats, but, you know, definitely we're seeing more folks using it. I mean, I kind of increasingly encourage people to,
35:31just because it's really easy, right? And, you know, it saves you a little bit of legwork of, you know, plugging stuff into the field. Like I definitely, you know, when I first set this up, you know, I obviously put some of the credentials into a document and things like that. So you didn't see me putting that in, but, you know, it was very quick the first time I set it up from scratch.
35:55And, you know, so I think it's, there's not really a lot of reason not to do it. I will say, well, for testing and things like that, I will say most commonly when folks get into production, they're managing infrastructure as code. So that's a little different and, you know, you'd have a different process there. I mean, you could still use MCP for that, but we have a lot of options. So we have an API, which a lot of our customers use.
36:20We have Terraform, which a lot of our customers use. And so you might kind of abstract one layer above and not necessarily use the MCP directly, but, you know, use cloud code and, you know, API, or what have you. But generally we're seeing a big move towards, you know, some kind of infrastructure as code implementation.
36:43We also have CLI, I can't remember if I mentioned that. Not to just list a bunch of stuff, but basically it's gonna be more and more common that folks manage it as infrastructure as code rather than ClickOps and UI. Yeah, that makes sense. Yeah, because I think like one thing that we're starting to see customers increasingly do is like have the first line of defense on like what I would call like SRE type stuff
37:07using like agents. And so actually having an MCP that can, you know, poke around through the config and be like, hmm, this pipeline is stale. Like, you know, let's look at the logs and do that. You know, obviously you can do the CLI too. So like, you know, just MCPs a little bit less config to get it started. And so we definitely are seeing a lot of people,
37:29you know, continuing to expand their capabilities that way and use that as like the first line to, you know, maybe kick off a message into the Slack app or something that says, hey, like we're seeing this weird thing, you know, check it out, you know, or sometimes even being like, you know, fixing it depending on how competent they are,
37:52their actions, but it's been really interesting. Yeah, for sure. We definitely, we see folks doing that. I find it very useful for that as well, debugging things and, you know, fixing issues. And we're doing a lot, we haven't exposed it all to the customer yet, but we have, you know, agents on the backend that are like, if something, if we see, get an alert, that there's an issue with the production pipeline,
38:15the first thing that happens is an agent, you know, goes to all the subsystems and analyzes what's happening, looks at the history there and says, hey, this is, you know, a transient spike that's common on this particular connector, or this is something that, you know, looks like a real issue and, you know, we need to dig into it. So that's another area where more is coming soon in terms of customer facing agents there.
38:39Yeah, it totally makes sense. We're doing, I mean, we're doing very similar things than other doc in terms of like, how do we make, you know, the system more reliable and respond more quickly and all those things, right? Totally makes sense. One more question here. This is a good one. Is there any friction in migrating from Kafka or is it near seamless?
39:01So if you're, if it's migrating from an external Kafka, I mean, it's pretty straightforward. Like we, like I say, we can expose our Kafka just like any other Kafka. So, you know, we've definitely seen folks move workloads from like MSK in particular, as well as like Confluent and others, or, you know, in some cases folks who tried to get
39:24to like kind of self hosting open source. And yeah, generally, you know, Streamkap is Kafka, it's open source Kafka under the hood. And so, you know, it's gonna behave just like your existing Kafka deployment behaves and it should be straightforward to migrate things over. Amazing. Okay, awesome. I don't think we have any more questions. I think we're gonna wrap up here.
39:48Paul, thank you so much for your time. Thanks for telling us and giving us a really cool demo of what it looks like to use Streamkap, especially now in the age of AI. It's kind of crazy to like do this all hands off now. there. Um, couldn't have imagined it a year ago, but here we are. Um, so, uh, and thanks everyone for coming out. Um, you know, we're, we're, uh, always super excited to show off
40:11this really cool stuff and, uh, what's possible with Streamkap and MotherDuck. So thanks everybody. We're going to end it here and, uh, we'll chat with you next time. All right, I'm going to end it.
