Listen on
Many organizations wrestle with a fundamental dilemma: how to effectively manage both real-time operational data and historical batch analytics without building two entirely separate, costly, and complex systems. The common approach of bifurcating data stacks for streaming versus batch processing leads to duplicated effort, increased maintenance burden, and higher cloud costs, ultimately slowing down critical business initiatives. This inefficiency affects ROI, operational agility, and the ability to derive timely insights for competitive advantage.
In this episode, James Winegar sits down with David Yaffe, CEO and co-founder of Estuary, a real-time data company. Yaffe brings a unique perspective, having previously built a real-time streaming system (Gazette) at his martech company to address immediate customer needs for actionable data. His deep experience in transforming this into a robust commercial platform illuminates the practical challenges and solutions in unifying data ingestion.
They discuss Estuary’s approach to abstracting real-time complexities while supporting batch needs, its differentiated change data capture (CDC) capabilities for sources like SQL Server and Oracle, and the strategic advantages of its connector development kit and Kafka broker for broad integration. The conversation reveals how a single, incremental streaming platform can drive significant cost reductions and enable new applications in areas like AI and real-time operations.
Key Takeaways
A single data platform reduces overhead and speeds time-to-value for real-time and batch needs.
Building separate data pipelines for streaming (e.g., Kafka + Debezium) and batch (e.g., Fivetran) is a common, resource-intensive pattern. Unifying these workloads on one platform like Estuary eliminates duplicated engineering effort, simplifies maintenance, and enables data teams to deliver insights and applications faster. This consolidation translates directly to reduced operational costs and increased agility for the business.
Decoupled CDC improves database performance and data fan-out capabilities.
Estuary’s change data capture (CDC) mechanism separates data extraction from its destination write. This approach, especially when handling write-ahead logs for databases like Postgres, allows quicker log acknowledgment and deletion, reducing database storage overhead. It also enables fanning out captured data to multiple destinations (e.g., a data warehouse and an operational application) from a single source connection without re-extracting.
Proprietary connector development kits offer superior reliability for complex enterprise sources.
While open-source connectors offer broad support, their inconsistent design and varying maintenance often create reliability issues for enterprise use cases. Estuary’s investment in its own Connection Development Kit (CDK) allows it to build and maintain robust connectors for challenging systems like Oracle and dynamic SQL Server schemas. This provides more consistent data extraction and schema management compared to relying on community-maintained solutions.
Incremental streaming significantly cuts data transfer costs and optimizes warehouse usage.
Traditional batch ELT solutions often re-read and transfer large datasets, leading to substantial cloud egress fees and increased compute costs for merging data in data warehouses. Estuary’s incremental streaming processes only new data, drastically reducing data volume moved and associated costs—often by 50% or more. This efficiency extends to warehouse usage by minimizing expensive merge queries during off-peak hours.
Related: CorrDyn helps organizations with data engineering to build reliable pipelines and offers data cost optimization strategies. Learn more about our partnership with Estuary or explore our thinking on how to skip the data stack for simpler data architectures.
Full Transcript
Jason: Welcome to Data BS, a show dedicated to tackling the big questions impacting the world of data and MLAI without any of the BS. My name is James Winegar. Each week I sit down with guests from across the data ecosystem to unpack how they’re shaping their businesses or the businesses of others through the real-world application of data engineering, MLAI infrastructure, analytics, and more. No fluff, unfiltered, but slightly edited during low noise. This is Data BS, let’s get into it.
James Winegar: All right, David, it’s nice to talk to you finally. We’ve been trying to schedule this for a while, so tell me who you are and what do you do?
David Yaffe: Thanks for dealing with my terrible schedule, post-baby schedule. I’m Dave Yaffe. I’m the co-founder of Estuary. We’re a real-time data company. We make it really easy to capture data from a whole bunch of different business systems, applications, databases, file stores, and then use it for practical purposes in real-time for whatever a business needs to do, like analytics, operations, or AI.
James Winegar: The underlying open-source framework is called Flow, if I remember correctly?
David Yaffe: Yeah, it’s complicated to be honest. The genesis story of the company is that myself and my co-founder had built a previous company called Arbor. Arbor was in the Martech space. I always believed that in Martech, you needed real-time data. The reason was because if you’re going to a website and searching for a pair of shoes, you probably want that pair of shoes right now. You don’t want it an hour from now. You probably already bought it in today’s world an hour from now. If you want to actually have any actionable data, you’ve got to use it immediately. We built this streaming system called Gazette to enable using that data immediately. Gazette is the thing after we sold Arbor, we said, we have this resource Gazette, we should really do something with it because working with real-time data otherwise is super hard. And I think we can make it a lot easier.
James Winegar: And then Gazette turned into Flow, which is the framework Estuary sits on now to basically run these data pipelines off of CDC or things like HubSpot, etc. What’s the complexity that Flow’s looking to solve?
David Yaffe: It’s really that businesses have data in a lot of different systems. The really high level is that they want to connect this data for uses like analytics and AI and other things. If you click one level down, the way that actually gets solved right now is people are using various different technologies and applications to solve those problems. One is, for the analytics side, you’re probably going to start with a batch provider like Fivetran to help you connect your data sources to a warehouse. Then you can do search or querying on your warehouse and get answers to your analytics questions. But businesses usually will build bifurcated solutions to solve the same problem. If you talk to the software engineering side of the house versus the data side of the house, they have two different ways of solving that. The software engineering solution is usually Debezium plus Kafka, whereas the data side might be Fivetran or something equivalent. Our technology, the goal is to make it so that you can use one thing to solve all of those types of problems because it will both handle the real-time nature and also the batch nature that you want for analytics growth.
James Winegar: With the majority of integrations within Estuary, at least as a user, I feel like you push towards the real-time, but the complexity of the real-time is abstracted away from you. Some of the integrations are every two hours or whatever because it’s a batch process that needs to run just by nature of the problem. And then some of them are supported by real-time, maybe CDC or time-based iteration. Give me everything that happened since this last timestamp I pulled and keep going through that process.
David Yaffe: What we do is our goal is we can only use the APIs or endpoints that are made available from a system. Our goal is to make something happen as quickly given those endpoints. If we’re serving batch APIs that update the data from the source every 24 hours, we can’t get any faster than that. But a lot of systems like CDC you can actually extract data with millisecond latency. As long as we’re moving as quickly as we possibly can given the API, that’s really our goal.
James Winegar: In our use case, we’ve got SQL Server, we’ve subscribed to I don’t know 500 different tables in the database, just keeps going through the poll. Because we have 500 different tables on that thing, it takes a few seconds. But if we said we only need these 10 tables, now the polling can be tightened up and we could get tens of millisecond type of response time from event happening in the database to it hitting our data warehouse. And then we could do even more interesting things from that point where we run a reverse ETL job or something like that once we get that event message that comes over and says we had an insert happen on this table.
David Yaffe: Exactly. That’s an interesting use case. Because even with databases it’s all different. SQL Server, Microsoft creates this method called Change Data Capture, which isn’t like all other change data capture. It’s its own special snowflake. The way that data’s replicated, you actually have to query individual tables one at a time to get the answer of what’s going on with newly replicated data. Most other systems have write-ahead log. Every single event just appears there one after the other. There’s no querying involved. That’s a good example of one place that latency is introduced by the vendor, the database creator’s method for extracting data.
James Winegar: But given that, we do as much as we can to make that data available as quickly as reasonably possible on our target system. High level, make it as quick as possible, when we can make it as quick as possible. When we’re forced by the system to batch out because API definitions or whatever, then you guys support that as well. You have this single system with a real-time first viewpoint, but supports batch workloads, batch data extracts as necessary. You can really do some interesting things. Actually I was on Slack earlier and saw somebody replicating from BigQuery to Postgres, which is not the direction I would normally be going, but maybe there’s some justification for that. They got data shared from a vendor and then they’re wanting to push that down into an application layer to support something.
David Yaffe: Yeah. Even if we go back to the previous example of SQL Server to a warehouse, we extract data continuously basically. But we can also introduce delays with pushing to your warehouse where we’re not pushing on the weekends for instance, if you don’t care about that data on the weekends. Only pushing within certain hours on the weekdays so that people are looking at reports only some times of the day. You don’t need to drive that warehouse in merge queries or expensive Snowflake credits or whatever it is during those off times.
James Winegar: You have this good separation between the data capture and materialization of that data that you captured. And because you offload the state to an S3 bucket or blob storage, whatever, you’re able to just go, here’s the last file I did all the bookkeeping on, etc. You handle a lot of the complexity basically. All that complexity around here’s the source data, did I land it yet, yes or no, not really a thing that the end user really has to care about because it lands in the blob storage and then you process it and you have all the watermarking, etc., based on the moving pieces. It’s really powerful from my experience. From the perspective of the system, you built Gazette which became Flow, which is this system to support moving data from point A to point B basically. One of the things I noticed when I was working on something with your team was that you pretty much have a super pluggable system as well. If Meltano or Airbyte or whoever supports that data source, then you also inherently support that data source. Are you seeing that the investment in time in supporting multiple different sync providers is providing you faster time to market for some of these connectors?
David Yaffe: I think this is a really weird and evolving area for us. What we’ve found is a bit counterintuitive, I would say. That was the reason that we invested in being able to run Meltano or Singer, Airbyte connectors. But what we’ve found is that they’re a little bit difficult sometimes because open-source connectors are built by a lot of different people. There’s an individual engineer that made design decisions to create that open-source connector. Inevitably for a bigger use case or a different use case, there’s something that’s broken with their open-source connector. It takes effort to actually be able to then advance those, evolve the connector. Sometimes what we’ve found is since an individual connector wrote that to some specification that no other connector’s built towards, it can take a lot more credits like engineering resource credits to contribute to someone else’s code versus just writing it yourself from the ground up. We’ve had this push in recent months and years to actually build our own connectors. It’s because even though there’s a bigger time sink up front, over time they take less and less effort to keep going. They’re all built to the same specification for Flow itself.
James Winegar: The maintenance burden is reduced because you have a specification that’s working for Flow itself.
David Yaffe: Yeah. We have our own CDK. Our CDK is what all of our effort’s going into now. APIs are all different. No matter what anyone tells you, there’s no such thing as a REST API that someone built a really good interconnect to. Stripe has things that aren’t correct when it comes to the actual integration of REST. And they’re an amazing developer-focused company. That means small connectors are going to be even worse. What we’ve found is we can invest in the things that look like each other. As long as our CDK has the option to drop in a thing that looks like this here and one that looks like that there, then it can really enhance the speed with which connectors are developed.
James Winegar: That means your time to market or your ability to onboard a new customer that has a unique data source makes you more attractive as a vendor. Fivetran probably has to go through a lot more product specification work prior to onboarding a source that they manage themselves. They only recently started allowing third parties to publish out their own connectors, probably because they feel some market pressure from people being able to move faster underneath them because they’ve gotten to such a big size now.
David Yaffe: I think so. I think there’s a total difference. We have three main categories of connector development. You have open-source, which arguably you can look at the numbers of connectors by the open-source platforms out there. They haven’t exploded in the way that they predicted that they’d explode. I remember when Airbyte first came out they were like, we’re going to have 500 connectors in our first year. You look at them now, they have like 35 total connectors that are approved by Airbyte. Open-source is one. The second option is what Fivetran does, which is they have an engineering team for each connector. That’s not sustainable either. You’re not going to be able to do that except at very massive scale. The third is doing something more like a CDK that helps you develop connectors with commonality to implement them across different options. That’s where Estuary is.
James Winegar: Could you walk me through some use cases that Estuary’s been deployed at and what basically differentiated Estuary from other vendors?
David Yaffe: I think our most basic use case is CDC and ELT. We have literally hundreds of customers that use us for that, to access their data in real-time. Some of them don’t care about real-time, they just want to point us at the data and say put it in this warehouse over there. The concept there is to just aggregate that so you’re not querying data in the database or querying your individual SaaS applications. You’re putting it all in one place, able to query it there. Going one level further down, we have real-time data products, I’d say. These are things that are more like customer-in-the-loop experiences. A good example would be we work with a logistics company called PlotFreight and they have a need for connecting their on-the-ground people who are actually working through deliveries to the package themselves. Those you don’t want to be off by 10 seconds with. You want to be truly real-time and be able to connect those so that the handoffs happen really quickly and easily. For something like that, you’re doing something more like creating a data product, which is creating a real-time view of where the package is to an individual driver. Maybe one more example. A third use case could be AI. Once you have that data that’s been curated for usage in a real-time use case, you could then push it to a vector database, vectorize it, and use it to maybe drive a chatbot so that now you have a real-time chatbot that you can potentially just query by asking it English instead of SQL.
James Winegar: A lot of details wrapped up in that. There is, and in varying success and varying maturity I would say too. On the CDC case, what makes Estuary’s CDC plus minus theoretically better than what Fivetran does? What’s really differentiating Estuary from the other competitors in the space at least for the CDC side?
David Yaffe: There’s a lot there. It’s a lot to unpack actually. Fivetran’s a very stable product. It works well. A few things that we do differently that I can draw success. One is we are not a point-to-point batch solution. That means we can drive low latency if the customer cares about it. That’s just one example. Another is that also driven by the fact that we’re not a point-to-point batch solution, if we’re reading from a database that stores the write-ahead log for a period of time, like Postgres or SQL Server, those are two good examples. We can actually always acknowledge the write-ahead log reads and so the database can delete data from the write-ahead log more quickly. That enables the database to store less data and never fill up. That’s a real thing that happens with Postgres. The write-ahead log can lead to a lot of extra storage. We are always making sure that no matter what we’re no more than a minute behind the actual write-ahead. We do that through a bunch of different things that we offer, but one is that we have a heartbeat. We have this capability to write to a table that we manage and we just write one record every minute if you use this capability. That record enables us when you see that record come through the write-ahead log, we can acknowledge everything up to that record because we know we’ve read up to that record. That’s a strategy that allows us to delete data really quickly, whereas if you’re using a batch solution, the fastest they’ll ever delete something is their sync frequency, which might be 15 minutes, it might be an hour, it might be a day. It could be a long time. And then if you can’t connect to the destination, they have nowhere to write that too. We can always write it to cloud storage if you connect to cloud storage, but they might have trouble writing it anywhere if your Snowflake password is down or something like that.
James Winegar: You decoupled the extraction of data from the writing of the data. That decoupling allows you to basically say I’m going to handle all the stuff I need to on the source and then I’ll worry about what I need to do with that as a secondary stage. And you can fan out as well. You were talking about point-to-point batch solution. It’s point to many points. You’re allowed to fan out.
David Yaffe: That’s actually a cool use case too. We see customers that start off just writing to Snowflake and then they say, I have a real-time use case now. How can I accomplish that? They don’t have to create another capture, they can just read from the same data and push it to a new destination.
James Winegar: If you have some API you’re consuming. It goes to Snowflake and then it also goes to things that support those types of use cases.
David Yaffe: We also have a Kafka broker so you can pull data from our Kafka broker. And anything that speaks Kafka, we can write to that.
James Winegar: What was the primary reason for going along the Kafka broker way? I think that enables a lot of interesting use cases, so what really drove you to invest the time in that?
David Yaffe: There’s a lot of long-term strategic decisions there. Imagine if you didn’t need to have Kafka within an organization. That’s realistically something that could happen in the future. But short term this enables any integration with systems that support Kafka. We got Tinybird, ClickHouse, StarTree, SingleStore, a whole bunch of these partners that we would have had to build individual integrations with each of them to be able to do that versus one Kafka endpoint that now supports that materialized and so on and so forth.
James Winegar: Basically went, why do I need to rebuild all these connectors for every little thing? If I just support Kafka, I get all of these destinations for free effectively. Are those the things my customers care about? If yes, this engineering effort was worth it. One of the things me and you talked about before also was Oracle, which I see as a place where a lot of the newer solutions don’t play as well with because Oracle’s painful to work with unless you’re Oracle. What is Estuary’s opinion on dealing with Oracle?
David Yaffe: I think it’s a great opportunity. It’s something that we do best support. We have two Oracle captures actually. One batch capture and then one real-time capture under CDC. We support Oracle, it’s a first-class connection now. I like it. We also support NetSuite, which is an Oracle product. That was another really big one to build, but it’s up and out too.
James Winegar: Yes, because it allows for just generic endpoints that you have to be able to subscribe to effectively.
David Yaffe: NetSuite has two integrations. One is an API integration and it’s super limited. The API endpoint’s actually pretty straightforward to build an integration with, but you can’t get that much data out. Any bigger customer needs the database underneath NetSuite. There’s an Oracle database and there’s no real exposed ODBC driver or something like that that you can pull data from. We have to build our own basically. It turns out to be a really big thing just because you’re interacting with this Oracle database that lies to you about the shape of the data and you just have to figure it out.
James Winegar: I’ve dealt with this problem before, the ODBC driver’s questionable. One of the things I also wanted your opinion on, one of the reasons we picked up Estuary originally was we have some SQL Server instances that we work with where the schema’s pretty dynamic I would argue. People are changing stuff a couple times a day typically. Estuary supports automatically managing the CDC connector on the SQL Server instance as long as you give it a role that has the appropriate permissions. For our use case, that was a pretty big deal because I don’t want to have to update this CDC instance on the SQL Server side every day and also figure out the state update, how to manage did you read everything off before I go and make updates to the CDC instance?
David Yaffe: Yeah, it’s annoying. It’s something we didn’t do for a while and we actually added two features to it pretty recently. The other one is automatically cleaning up data from CDC tables, being able to once we’ve read a certain amount of data just deleting it from there. Between the two of it makes CDC really low impact but also always have the capability to find columns and know the shape of your data changed. I’ll tell you schema management has been such a long journey for us. Being able to react to changes in the database or the source system and then be able to manage the destination as well. Having to do stuff like widening columns in the destination set them when you widen columns in the source or changing the column type totally or changing primary keys. These all weigh different solutions, so it’s something that you don’t expect to be as complex as it is, but that’s something that I think we do pretty well now.
James Winegar: Basically anybody can do anything and you don’t have that insight directly. All you get is the DML. People do a lot crazier things than you’d ever think they’ll do. I think that actually ties in pretty good to a transition to talk about the product from the less technical side. How you have this UI that you’ve built on top of Flow that supports all of the moving pieces of managing these different types of changes that you might deal with. And you have an underlying CLI that does all the same stuff for practical purposes. How does this approach help you manage your usability of your product?
David Yaffe: What we find is that most customers start by using our UI. That gets them through all the initial setup usually. But then there’s bigger companies out there where you want to be able to know that a data flow will always be set up the same way. You want multiple people to be able to manage those, evolve those data flows. Maybe they’re making changes at a large scale. Changing a whole bunch of different tables and the actual columns that we’re pushing and the names of those columns. It wouldn’t be really feasible to make those types of changes within a UI. Our philosophy was we always need to have some sort of way to make these changes programmatically. We actually built our CLI before we built our UI, which is a bit weird. That enabled us to build our UI on top of the same API that we use for the CLI and that helped a lot. I think when it comes to mass changes you absolutely need a CLI for these types of data flows. Also when you’re setting something up so that you can be sure that it will always be the same, you want GitOps. You need to be able to have a set of YAML files that you can put into version control and then be able to have multiple people on a team check it as you make changes, update those and then re-check it into version control once you’ve made those changes. Those are the types of workflows that we wanted to be able to support. We see customers commonly doing those. They almost do it in a pattern where they start off using the UI and take some steps towards first CLI usage and then automation and GitOps. There’s so many complex pieces though. I’ll give you an example. Originally this was a really bad design decision, but we made our MySQL connector, one of the daytime types was a string. We pushed it as a string to the destination. It’s brutal. But now we have the fix for that is super easy. The fix is to change it to not be stringy anymore. But a lot of historical customers are relying on that being a string. How do you actually make an update to change the type of a field from a system where customers are dependent on it? All of a sudden you add a time variable to this. You have to track over time when something was made to understand if you should push it as a string or something else or whatever. That just brings the complexity through the roof. Now you got this if statement that lives inside of your system for however long. However many bad decisions you make you have to carry them forward. Making better decisions up front can reduce your overall complexity dramatically. Another thing that could be complex for you is you have these Airbyte, Singer connectors that you leverage. And then you’re moving towards Estuary’s CDK, connection development kit to say, I want to use our CDK for I don’t know MySQL connector because you’re making this change. How do I change over people’s connector too? So it’s not just how do I process that data, but it’s also what connector’s being used and those types of things. And what do you support? You can’t support every version of everything. And then you want to transition people to using a new one. You want to make that easy for them to transition. It’s hard. All of it’s complexity that we didn’t really realize we were taking on from day one I guess.
James Winegar: How long you been working on Estuary now? Seven years?
David Yaffe: About six. Been a long time. But as far as customers, it’s been the last one or two years that’s really started to take off. Four-ish years of building out the core underlying infrastructure to support all this complexity that we’re talking about. It was a huge time commitment from a build standpoint. If we decided to just go batch or streaming instead of both, we’d divide that by two at least. But we chose a hard thing and it takes a long time to get it right. In choosing that hard thing, you have the single platform that supports all the use cases. From a market standpoint, this’s probably going to be better because you’re like, yes, I can work for your use case. Instead of, I only work for this one use case, but you still have to do all these other things and I don’t know Fivetran. That’s not the case for you. You can be like, no, I support pick your API, pick your database, pick your whatever, we can support it. Exactly. And hopefully it’s quick too. My favorite thing is when we first sell to an analytics team and we sell some non-real-time just standard use case. They’re probably doing something like transitioning from another competitor I won’t use any names to us. Then later on, six weeks, six months later, someone from the team says, I was in an internal meeting and we were talking about this real-time use case and they were all thinking about bringing on Kafka and Confluent and Debezium to solve it and I was like maybe you can just use what we have already. Then an aha moment goes off on the company’s head and they’re like, damn, this actually worked. We can use one tool for all this.
James Winegar: For one of our customers where we already transitioned them to Estuary because SQL Server support is very, very good in Estuary. We have a Census sync that we’re using for reverse ETL because of the other systems that are in place that are batch for a reason. Basically the same thing. It’s like, okay, it would be better to your very first point you talked about with Martech, because this is driving a sales slash marketing thing. If I can push that down into real-time, milliseconds or seconds. Now if we do that we can dramatically simplify the system because we’re not having to do this batch process where we’re trying to figure out what’s the latest record and which order do we need to do it in. No, we got the event, we process the event. That has other simplicities that come along for the ride. It’s like, okay, we’re going to bring those other sources into Estuary’s real-time connectors. You got to update some transformation logic and things like that, but at the end of the day we’re going to take a thing that’s a two-hour SLA basically to hopefully a 10-second SLA. From a practical standpoint, real update time frame’s going to be one to five seconds because we have this SQL Server with 500 tables.
David Yaffe: Which is pretty good. That’s as good as obviously you can get with a SQL Server like that, but I think reverse ETL is a pretty exciting thing for us. We haven’t really built many of the SaaS destinations for that, but you can definitely see in 2025 we’re going to build Salesforce and HubSpot and the major ones at least that you get use out of. And then we have a streaming SQL transformation engine ourselves that doesn’t even have to go into Snowflake or BigQuery, you can just push it direct from us.
James Winegar: You already have all the supporting technology built in. You get the event stream, do whatever windowing’s required, push push push. And you already have the fan-out capability too. If you want to send the same set of events to three different systems, okay, y’all, this is what you need to do now, move on with your life. What type of cost savings do you think people get with using Estuary as compared to other vendors in the space?
David Yaffe: I think we’re able to offer some sort of pricing benefit mostly because of the fact that we’re again a streaming system, we do things incrementally. Instead of re-reading the same huge set of data over and over and then shipping it over the wire and incurring a whole bunch of egress fees from our cloud provider to your cloud provider, we’re able to actually do most data flows incrementally where we’re only pushing new data at any time. That really does help and provides a lot of pricing benefits. Usually we see 50% at a minimum cost savings between us and unnamed competitors I’ll say. But the thing that’s exciting for me isn’t the cost savings, it’s just the fact that you can now do more things with the same system. Instead of once you were stuck using something for just analytics purposes, now you can bring it on and actually bring it to the engineering side of the business for software engineering purposes. For me what I’m thinking about is just I can support all the use cases, real-time and batch, and the vast majority of our use cases are batch. But the times where it’s real-time, typically it’s a custom system that gets built out and got all this state management and yada yada yada that you end up rebuilding the wheel 50 different times. You have three engineers that are dedicated to feeding and watering it. Just those three engineers that are on that could be building something that was actually helping your business. Instead of maintenance.
James Winegar: All right, it’s been fun to talk to you David. Where can people find out more about David and Estuary?
David Yaffe: Our website’s getting better, we’ve spent some time on it, estuary.dev, that’s probably the biggest one. We’re also on LinkedIn. Those two are where we do, we’re not too into social but where we do is probably LinkedIn. You guys have GitHub /estuary as well. Exactly, GitHub /estuary. And then whenever I work with y’all stuff we just talk on Slack, there’s Estuary Slack. That’s our best place. If you want to speak to someone our engineers are actually on our Slack channel and you can get a response from an engineer anytime of the day basically. I’ve worked with your team a lot and very responsive is what I’ll say. We try to promote that culture, I think it’s super important.
James Winegar: It’s great to talk to you David, hope you have a good day. Thanks, you too.
Jason: That’s it for this episode of Data BS. If you enjoyed this episode make sure you subscribe wherever you listen to your podcasts and not miss the next one. This episode was sponsored by CorrDyn, a data consultancy that helps organizations unlock the power of their data. If you have a data challenge, we can help. Visit corrdyn.com, C-O-R-R-D-Y-N dot com, to learn more. See you next time.
