Drill to Detail - Drill to Detail Ep.40 'Fivetran's Middleware for SaaS Data' With Special Guest Taylor Brown

Episode Date: October 16, 2017

Mark Rittman is joined in this episode by Taylor Brown from Fivetran to talk about middleware for SaaS data, their focus on integrations with SaaS vendors and how this differentiates their offering, his thoughts on packaged analytic applications announced at the recent Looker Join conference ... and where the name "FiveTran" came from.

So welcome to another episode of Drill to Detail, the podcast about big data, data integration and business intelligence, and I'm your host Mark Rittman. So a couple of weeks ago I was over in San Francisco for the Looker annual conference and had the pleasure of meeting today's guest, Taylor Brown from Fivetran, a company I'd heard a lot about from my good friend Stuart Bryson. I've been meaning to ask onto the show for a while. And so I'm very pleased to welcome Taylor Brown, Fivetran's CRO and co-founder, onto the show. And hello, Taylor.

Hello, Mark. Thanks for having me. So, Taylor, tell us a bit about your, I suppose, your kind of career so far and your history and how you came into kind of founding 5Tran and so on. Sure, so I actually don't really have a background in analytics. I, right out of college, joined a startup company from a few other people I knew in San Francisco and essentially moved from Colorado to San Francisco and dove right in, working at a company of three people. That company was building applications for Facebook. That was around 2010. And I learned a lot in just overall running a

company. Essentially, my friend and I were running most of the company and we had two other partners that were building, um, uh, kind of doing client work on the side to help fund the company. Um, and so learned a lot about, uh, the, the, you know, the, the problems, the challenges involved in starting a company. And, um, and part of that was some of the analytics stuff. So a lot of times we didn't really know, you know, what was happening. And I remember actually at one point we had, um, really, really large brands using our Facebook applications that they weren't paying us what they should have been. And we had no way of like checking, you know, what levels they were at and things like that. So that was a pain point that I held onto. Um,

and then, you know, fast forward a few years later, the company, that company was acquired. Um, and I decided to join a company or to start a company with my co-founder george he's much more technical than i am but i bring more of the business acumen um in the business side so we joined forces and that was really kind of the beginning of it okay okay so and certainly that that whole world of you know you say you worked you had a product that was kind of doing facebook ads and that sort of thing that whole that whole kind of world of analytics and advertising and marketing ops and marketing analytics and so on around that world is kind of very interesting and the world I came from was more I suppose kind of classic ERP analytics and that kind of world but it's very it's kind of like almost like a parallel universe

really isn't it so that's the world I came from it's it's similar kind of outcomes but very different kind of vendors ecosystem scale of data and I suppose kind of outcomes, but very different kind of vendors, ecosystem, scale of data. And I suppose kind of, I suppose, in a way, velocity of change, really, in that industry. Yeah, yeah, I would definitely agree with that. I mean, there's obviously a lot of data, but there's, you know, very different outputs, very different vendors, you know. But it was exciting. I mean, it was a fun place to work. It was a great opportunity right after college.

And I think I learned a lot learned mostly that i just enjoyed building startup companies so that was that was really for me i think the biggest learning thing from that experience and then bringing that right into five trend okay so so tell us what tell us about five trend then you know what does it do uh you know what is the product that you sell um and and and kind of in a, what problem are you solving for customers, really? So, Fibetrend provides data connectors for replicating data from our customers' source systems into their central data warehouse. So, what that means is we connect to SaaS solutions like Salesforce and Marketo and HubSpot and Google Analytics and MailChimp and NetSuite and I think 30 other different data connectors. And we just replicate all that data into our customers' warehouse. And then we actually create the schema, we create all

the tables, and then we just continue to keep that data up to date every, you know, one hour, every 15 minutes. And so, you know, we support SaaS solutions like the ones I mentioned. We also support databases like Postgres, SQL Server, Oracle, you know, and a plethora of other ones, Aurora, Mongo. And then we also have event collection. So for bringing raw events that you can send to us, like, you know, click events or web hooks or that sort of stuff. And then lastly, we have some file uploads. So like you can upload files directly into your system.

And the way I really like to think about it is we are a toolkit for analysts and for IT teams, but more really focused for analysts that we're their toolkit for helping them get data from all the different places that they have to get it together so that they can actually do the hard work in analyzing it and not have to focus 40 or 50% of their time

on just trying to pull all the data from these different places. Okay, so you mentioned that analysts, and I guess the kind of the initial reaction of someone like me would be, well, this is a market that is already well-served, and there's lots of data integration companies out there. But you mentioned analysts there, so that's quite a different type of, I suppose, user persona to the traditional data integration tools I'm used to, where the actual user might be, say, an IT worker or IT department or whatever. Are you aiming a different type of customer that the people you know that say informatica would aim at and things like that definitely I mean I think we

still serve the IT professionals as well as the analysts but I think what really has shifted and I know that that that the you know they talked about a lot the looker joint conferences was just these is the shift from IT having to put together all of the stack for the entire data stack. So IT is bringing in Informatica and bringing in their own programming tools and whatever else, and they were in charge of doing a lot of this pre-aggregation

and loading into the warehouse and everything else. And now there's much more of a self-serve type philosophy where it's not necessarily removing IT, but it's allowing IT to do their job and being in control and understanding what data is available and everything else. But it's also allowing the analysts and the end users, the business users, to actually access this data in a more self-serve fashion. And so I think we really believe in that world

and that it should be not a lot of time, energy, effort that customers and companies are spending on pulling and aggregating and doing all this kind of stuff, but rather they you know, they should choose tools like Fivetran that are fully managed and they should choose warehouses like Snowflake or BigQuery that are fully managed. And they should essentially try and, you know, make that first part of their entire pipeline completely managed and not have to think about it and not have to worry about it and manage it. And rather than spend their time focusing on

getting their analytics correct and running their business correct okay so so is is fivetran um like a sort of service that people subscribe to or is it a kind of piece of software they install on their own servers i mean how's it typically delivered and and kind of sent to customers yeah so it's all software as service so we are a cloud-based tool uh tool that can set up in a matter of minutes and and then you know essentially you set up a relationship or contract with us and we then make sure that the data that you have from all your different places is continually delivered you don't pay any extra server costs or anything like that

because you're essentially handling all that so why would i suppose the obvious question with these kind of products is well how do you convince customers to pay for your service rather than say use something like airflow or use super metrics or use some kind of free service really i mean what what's the additional value that you guys kind of you know pitch to customers to say this is kind of worth it compared to doing it yourself? Sure. You know, I think that a lot of the free tools or even the paid tools like Informatica, the challenge that they have is that they give you this framework and then they say, hey, here's an easier way for you to understand

and build these connections. But ultimately, at the end of the day, you're responsible for them. So you build them, things break, you have to fix them, you have to monitor, you have to manage them. So you build them, things break, you have to fix them, you have to monitor, you have to manage them. Versus with Fivetran, you just click, click, connect, it's running, something breaks, it's 100% on us. Our guarantee to you is that we're going to deliver data day in and day out. And you literally don't have to think, we kind of think it's know, it's a set and forget sort of situation, um, where, you know, you set it up and then you forget about it. And then, you know, not to,

you know, uh, not to, to, I guess, belittle ourselves, but I would say in some ways you can compare us with like plumbing in a house where, you know, you, you know, before you'd have to go and you'd go to the well before plumbing and you'd have to like grab the water and just bring it in versus once you hire someone to put plumbing in your house you put it in there and then you kind of forget about it and you just get used to having the faucet and being able to go and get water or take a shower whatever um and it's like you know i think i i often use this analogy but and i think that it is very very basic but it also just is a good analogy for what we're doing. Okay. Okay. So, so you, I suppose in a way drilling, painting a picture really of, of, of, of a, of a kind of a five trend deployment, if we look at the sources and targets and so on,

just to try and get a bit more kind of, I suppose, picture of it. So you mentioned in terms of sources, you talked about their things like Facebook and so on and, and SAS applications and so on there. I mean, so tell us about some of the things that you connect to. And I suppose the challenge is really in doing that, because I guess that you have to keep in sync with how the sources change. You're not necessarily kind of like getting that information directly from those vendors. I mean, how does that work and who do you connect to? Yeah, that's a good question. So the strategy that we have for connecting

to every source is slightly different. There are categories of sources. So what I can say is generally the cloud application sources, we connect to them and then we pull from the APIs and typically we're using, or actually taking one step back, we do incremental updates for every one of the data sources that we have. So that's by default, meaning that we're doing some sort of change data capture to make sure that we're not duplicating our efforts,

which is really critical. We can't pull a huge, the same table every single time because we're going to blow through all the API calls or the APIs are really slow, whatever. So for cloud applications, we pull usually using some form of last modified date from each table. And then we go through processing it and normalizing that data

and then loading it into the warehouse. From databases, we pull using the log replication. So we're typically tailing off of the logs. We essentially become a slave database onto your database. We're tailing the logs. And this is, one, far more efficient than actually querying against the database. So you're not having undue loads on your database. And two, we get every version of every change,

which means we get deleted data, we can build history tables. We just have a much greater understanding of the changes that are happening in your source system. So that's cloud applications and databases. Cloud storage kind of works the same way as databases. So like your S3 or SFTP or cloud, Google Cloud Storage, or blob storage, we're pulling just the change data.

The one that's complicated that you mentioned was the, as we call them, cloud reports, the AdWords, Bing, Facebook Ad, Insights, Google Analytics, where they do not give us, unlike everything else where we get access to all the underlying data, all the row level data, in the Cloud Report APIs, we only get access to pre-aggregated reports. That's partially because these are extremely large tables that they deploy. I mean, the AdWords data sets are enormous. And also, I think that Google is going to never probably let a lot of information out.

They're not going to let the names and the gender and all that kind of stuff of every single impression or every single person. Because that's their, you know, basically that's part of their property. So they only give us those reports. And so we're only able to pull out pre-agreed reports. But fortunately, we can pull out any report from any of those different services. Okay. Okay. reports but fortunately we can plot any report from any of those different uh services okay okay so so i mean we had jake steen from from stitch on recently on this on the show and we're talking about stitch and stitch is the obvious i suppose comparison what you're doing here but before we

get on to kind of that something that they talked about was their singer um uh open sourcing of the kind of connectors really they're doing and and in their in their point of view you know the connectors were almost a commodity and it was actually the kind of the really they're doing. And in their point of view, the connectors were almost a commodity and it was actually the kind of the server-based orchestration and managed service that was the main differentiator for them. But you're talking there very much that the connectors are a really kind of differentiator for you. I mean, is that something you kind of think is the case

compared to say open sourcing it or what? Absolutely. I think you hit the nail on the head with that one um you know jake's uh uh has become a friend of mine it's a good guy you know i think we have different philosophies about how we think about this business i mean in practice our tools are very similar in some ways um you know the principle of those are very similar, but I think that's one of the big differentiators is they're thinking about it as the values, the orchestration,

and being able to plug into it and open source and build an open source community, which is fantastic. I think that makes sense in a lot of ways. It's just not our perspective on it. We think that building these actual connections is really difficult. For us, we're all about quality. We want that building these actual connections is really difficult. And for us,

we're all about quality. We want to make sure that the connections are extremely high quality. You know, the normalization of them is extremely good. They're going to work day in and day out. We can't give that stamp of approval on open source. So we dedicate ourselves to just making sure that we just build every integration we possibly can. And it gets that five-transit approval that has a really fantastic schema. And it comes with an ERD. And it has, you know, all the data is normalized in a way that makes sense to both the business user and the analyst. So that would be one of the largest differences between us and Stitch. Okay, okay.

So taking a step further, you land the data in the target platform, and then I understand that with Fivetran, you then go on and cover the transformation part of it as well. Is that the case? I mean, talk us through that, really. So that is not really the case.

At some point, I mean, in that way, we're very similar to Stitch. We load it into the warehouse and that's it. And then basically it's there and we will continue to manage and maintain the schema, that base layer of tables that we've delivered. We essentially continue to maintain them and change the schema and do all this stuff, which is similar to Stitch. We do have some plans for some additional stuff once you load it into the warehouse.

That is probably coming out at some point in the next six or eight months that will handle a little bit more orchestration and things once data is loaded into the warehouse. But the critical thing is that it is an ELT platform where you load it in the warehouse and then information happens downstream of that and most of our customers are just doing that just directly in SQL you know some of them will end up using like an Airflow or some additional orchestration tool after it's

loaded but I would say 90 or 80 something percent are not at this point doing much else besides just using SQL and maybe PDTs things like that inside of Looker. That's interesting. Okay, so the reason you're not covering the transformation part

is partly because it's something you plan to do in the future, but largely because of, I guess, the schema on read nature of this data. Is it because people tend to have lots of different ways they want to transform it, or is it because they can handle it much more kind of easily using SQL? I mean, what's your thoughts on that? Yeah, I mean, I think that the big shift that's happened in the last few years, being the technology shifts that have happened, have largely changed the behavior in these stacks.

So if you look at it, you know, 10 years ago, the cost of data storage was much higher. The data warehouses people were loading into were generally not Columbia data warehouses, and they were just not that powerful. So as a result, everyone was focused more on doing an ETL sort of workload where you're taking the data, you're transforming it, you're pre-aggregating it, and then you're loading into the warehouse because you're trying to make sure that that data, that pre-aggregated data, those cubes are as small as possible. And what's changed is now the cost of data storage has gone down. There's fantastic columnar data warehouses like Redshift, BigQuery, Snowflake. And so as a result, I think everyone's switching to now do more of just the ELT, where they extract it, they just load it directly in, and then you're doing the transformations inside of the SQL layer.

And the reason people weren't doing that before is just because everything was coming pre-aggregated into that layer already. But let's remember that SQL has been designed and optimized over the last 35 years for doing a lot of this exact stuff. And so by using, you know, on top of these base layers, which is relatively easy, you can end up with a lot of the same transformations that you'd be doing outside of it, but you're all within the SQL layer that is standard, that your analyst team knows, that, you know, both your IT team will also know. So it really just, I think, makes a single place where you can do a lot of this work, where you're not end up using these highly specialized tools

like Informatica, and you're not having to build this stuff in code using Python or Java or whatever you want to use. So that's the big shift that we've seen. So are you finding, I i mean so you talked about things like you know taking data from facebook ads and and classic kind of um i suppose you know marketing type use cases are you finding that with the with this rise in these uh columnar databases like athena like kind of big query that you're starting to get customers coming to you from a more traditional background who are looking to move more traditional data warehouse workloads onto these platforms? And are you getting

involved in those as well? Yeah, we definitely are. I mean, we're starting to see more of that, you know, where customers are moving over to like a Snowflake or a BigQuery and they, you know, they're moving over from Vertica or, you know, Natisa. And it's usually the kind of thing where it's, you're moving off of an old, you know, a classic enterprise data warehouse is it's a time consuming thing, because there's your have all of one, the ETL that's going into that warehouse, but then you also then have all of your, you know, business logic and everything else you've built on top. And so untangling that can be a really complicated thing.

And we definitely have customers who are doing it and they're trying to simplify and build version 2.0 of their pipeline and their data warehouse. And they're using like Snowflake. And so we're seeing that a lot, but it's not the kind of thing you just rip out in a weekend. You know, it's the kind of thing that's going to take a year, 18 months months and so we'll see them set it up and they'll set it up with us and they'll be running things in parallel for a year longer as they're building and moving things over piece by piece yeah i mean that that's that's been my observation certainly when i first started working with with kind of big query is that you try and reproduce what you know from kind of on-premise databases and you try and reproduce a lot of the complex logic around kind of dimensions and so on.

But, you know, my advice now is typically, you know, move the workload but not necessarily move the design. And not everything needs to. I mean, I think Snowflake can be an interesting one because it does allow you to reproduce a lot of that. But I don't necessarily think that all workloads can move into this environment and and a tool like five tran is is not a kind of general purpose etl tool it's it's it's you know it's for connecting to these these data sources that aren't owned by the customer they're managed as apis and so on you take care of that as a contract for you

exactly and you move it in kind of balkan and there, really. That's right. But even if you think about it in the same, you know, the more classic way, and you're saying like move these workloads, like move the workloads over, you know, I think we, you know, customers can still do that. Like they can still, like instead of using it, you know, informatic or something to load this stuff and stage it and then load it into you know, a net ease our vertigo I think that what was functioning that they loaded into a Snowflake and they have in those space tables and then they can build this safe the same exact orchestration layer on top of that You know and sometimes we'll even end up using like an airflow or something like that Or a dbt or whatever to then, you know orchestrate that same layer is the same way they did it before where they're building a cube they're then you know putting you know something on top of it

or they'll use something like looker which is a new edge where you're still building a cube you're still building you know essentially a pivot table layer that you then have your users working with it so the shift at that end has not changed so much in terms of the actual aggregations and the way they're building cubes and things like that i think the shift on the bi end is now that it's just all web-based it's much more collaborative and it's a lot easier and faster to work with i mean so you and i are both at the uh the looker partner event um the other week and that's how i kind of saw you the first time and um yeah we were we we were hearing kind of Looker's vision about their platform going forward and the analogy they made about, you know,

in a way kind of monolithic BI was blown up years ago and now it's been broken up into the individual parts of which, you know, Fivetran is one of them. So that was kind of a good story. But, you know, what was your take on the Looker event? And I suppose the kind of use cases you're seeing there and the potential synergies, I suppose, really, you know, between Fivetran and Looker event and I suppose the kind of use cases you're seeing there and the potential synergies I suppose really you know between between Fivetran and Looker. I think it was a really fantastic event I mean I think they just continue to gain momentum and they're you know

the product continues to get better I think that they've really listened to some of the things that they're not great at and have continued to work on those. Overall, us fitting into an ecosystem with them and us fitting into the ecosystem in general, I think that that is really important to us. I think that that's what we're seeing more and more of. And so what I mean is, you know, and I think we talked about this briefly, is that there's all of these different tools. But what makes it powerful is how closely these tools can combine together to make a single solution. So instead of having to duct tape them together, they just already think about it very well, and they sit very closely together. So I think, for instance, Looker and Fivetran work really closely because we deliver these base tables. They have this powerful modeling layer that then sits on top of it.

And then you have your BI. So it allows you, a customer, to go from having nothing to having at least a full warehouse set up and having their entire Looker instance within an afternoon, literally. We've gone through it a bunch of times um and i think that that's you know the having the very tight partnership ecosystem like that makes it really easy for consumers to come in and say okay i'm going to set this whole thing up it works very closely together um you know in in in actuality there always is you know random side things that you need that like five trans not going to support or even Looker is not going to support.

But then usually there's going to be another vendor that hopefully will plug in there very nicely. And I think that that's really where the space is going. And we're seeing more of that. I think what I'm excited about some of the stuff that Looker has been focused on is not even necessarily regarding their technology. It's small stuff like their Looker blocks. I think blocks are an extremely powerful thing because what it allows both Looker and Fivetran and other vendors that provide data replication or data integrations or ETL or ELT is it allows us to come together and package an entire solution for a customer.

So when that customer comes in, they're looking at, hey, they're more interested in buying a solution than they are buying a set of tools. Because sometimes there can be so many tools in the ecosystem that you just have no idea what the right thing is. But if you are able to say, look at these blocks or look at this end result, look at this marketing dashboard of these four different sources that you're interested in, and we can have this set up in an afternoon for you with Looker and Fivetran and say BigQuery, that gets people more excited, right?

So then they're like, okay, this is cool. Let's try this. And then they see, okay, great, this is a full dashboard. It's got everything in it. And then really the big aha moment is when you get the rest of their team looking at it and they say, wow, this isn't just like an Insight Squared or a good data or something where you can't really change any of the analytics. The dashboard is the dashboard you get.

But then they start to look at it and say, oh, my gosh, we've got this and I've got this and I can pull these other data sources in. And they start to realize this is an extremely powerful platform but it's already fully configured for me to understand it and get value out of it from day one. I mean, that's interesting. I mean, that, of all the announcements that Looker made that week, that was the bit that made me kind of raise my eyebrows a little bit.

I mean, I can totally see the value proposition in that, in that, as you said, you get a solution rather than a platform. But, you know, my history is being involved with Oracle technology, and they had a series of packaged applications, and they controlled all the different parts of it. They controlled the source,

they controlled the dashboards, and so on. They actually OEMed the ETL part from Informatica. But the point of it was that it actually, in the end, wasn't a particularly kind of good solution for the customer because they you know the the packaged ETL almost inevitably needed to be changed to reflect their actual implementation the dashboards were never actually kind of what customers wanted and I must admit I actually kind of looked at it and I thought well this is I can see the appeal but it's it doesn't turn out well for Oracle at the time I mean I mean I suppose the fact that you've got APIs and it's more flex't turn out well for oracle at the time i mean i mean i suppose the fact that

you've got apis and it's more flex i mean how do you see yourself not falling into that same trap with that really well i i think um not not being uh i don't have a an experience particularly with oracle but you know my thought is that those are probably fairly hard to change um and the difference is with you know with with look, it's a lot easier to change. It's really more of like a jumpstart program. And the expectation is not that this is going to be the dashboard that you're going to have forever or the set of dashboards. It's like this is going to get your idea and thought jumpstarted.

It's going to give you some things that you should be looking at from these different data sources. And then you're going to continue to add on from there um so i think of it more as like a foundation tool a jumpstart tool than a this is set in stone here's the dashboard that you want you know yeah i mean it's interesting i can see exactly why they would do it i mean it's a product that will sell very easily because people want to buy solutions and so on but it's it's um certainly i think it would have to be done in a slightly different way and i think the way the way that etl is done now with kind of

data engineering and so on is much more designed to be flexible and changeable but but certainly in those days an etl routine using written using informatica was was you know it costs it costs a fortune to change it really so yeah it's interesting yeah i think they got to i think it would be popular but they gotta do it well yeah yeah definitely and so it is still an you know an immature product i think that they've got some more work to do to actually productize it and make it easier for you know vendors like five trans to come in and help build these different blocks because right now it's a it's not exactly productized but i think as they continue to add more, you know, they prioritize it more,

I know that there will be more interest from, you know, the Fivetran's in the world. Okay, okay. So looking just at the end, just looking forward, really, I mean, it sounds like you've solved the data movement problem and you've solved the issue

or certainly addressed the issue about, you know, sources changing and so on there. You know, for Fivetran, what's the next problem that you're trying to solve? What's the next, I suppose, kind of frontier really in this kind of world? I mean, I think that there's always more that we can do, just in what we're already doing. I mean, I think that that's one of the things, again, that separates maybe the stitches from the Fivetrans

is just that we're extremely focused on making sure that the connections that we do have are unbelievably good. and so we're spending a lot of time you know continually going back and rebuilding the integrations that we have or the connections that we have um and that's going to always that's going to kind of probably be going on forever um and so you know the first frontier is just making the integrations we have great and and then and then from there it's adding more of those So making sure that we have really wide, making sure that we have every different type of connection that customers are going to want.

And that's already what we're doing. I think after that, there's a lot of different things that I think we could work on from a product standpoint. There's definitely some gaps. After we load the data into the warehouse, before it goes even into a looker modeling layer, there's still some gaps after we load the data into the warehouse before it goes even into a looker modeling layer. There's still some gaps where, say, if you're working with a ton of JSON and you're loading into Redshift, there's not a lot of easy ways to unpack that JSON.

We do a little bit of unpacking of that, but there's some things like that that I think we could potentially add some value. There's potentially maybe some scheduling stuff that we could help with, given that we have really great in-depth understanding of when the underlying data has been updated. So there's maybe something around that. And these are things we've been thinking about,

and we haven't committed to anything in particular fully yet. We're just also in supporting larger customers. So that's just larger volume sizes, connecting to more on-premise systems, handling more of that sort of stuff. Those are some of the big things that we're working on right now. I'm sorry to say nothing that revolutionary. Well, that's interesting in itself, really. I mean, it's always a working product myself,

and it's always a temptation. Not a temptation, but there's always customers will give you a million different ways you can take things, really. And it's that kind of balance between, or I suppose kind of decision, isn't it, between do you kind of stick to your core thing? Do you expand out? You know, what's the vision for kind of Fivetran going forward?

Is it, you know, have you got this kind of wider vision of of kind of a bigger thing or try and get this thing correct i mean i suppose also you've got the the challenge coming in from things like aws glue for example uh you know a potentially quite transformative kind of technology but i guess that's looking at a different problem space that's about on-premise systems that need to be discovered and so on. Whereas your sources, I guess, are quite kind of well known. It's just they're difficult to connect to. That's right. That's exactly right.

And, you know, I don't think there's going to be a single tool that wins out in this space. I don't think it's going to be like, OK, you know, glue has now become the thing. I think it's going to be, again, a lot of tools that you then put together very closely and you'll use five trans for some stuff you may use glue for some stuff um you know and you use this combination of different tools to fit your needs okay okay so two rainy questions for you actually uh taylor first one is what's that noise in the background is it you know you knew a pool tour or what it's the it's just the horns from outside i'm uh we're on the 12th floor here 10th floor here but um you can still hear them honking down there oh fantastic

and the last question is five tran what where's the name come from what does that mean uh walk do you have any guesses i've no idea actually no what it from? So it's a play on words of Fortran. Oh, right. All right, okay. So when we first started Fortran, we were initially working on a numerics platform. We were going to do a couple of things, just how to make data easier, more accessible to customers. And we thought Fortran was the original data language, and we wanted to be the next generation of data tools. Okay, okay, fantastic. Well, look, can we see you at any events coming up? Are you speaking anything or exhibiting at any events coming forward? We will be present at the reInvent, AWS reInvent event, but we will probably be sponsoring

at the Looker join event in Europe. I don't know if they've fully published but we will definitely be there in early spring. Okay and last thing is how would people find out about Fivetran? What's the website? What's on there? Just kind of anybody who's interested having heard this. Sure yeah go to Fivetran.com and there's you can easily get in touch with sales or there's a demo form if you want to get a demo. You can also reach out to me, taylor at fivetran.com at any time and I'll be happy to answer any

sort of questions. That's great. Well, thank you very much. Do appreciate it. It's a nice early in the morning for you. So thank you very much for that. And it's been great to speak to you. Thank you.

Yeah. Thanks, Mark. Thanks so much. so thank you much for that and it's been great to speak to you thank you yeah thanks Mark thanks so much