The MongoDB Podcast: how Datasite engineers scale its M&A platform

• Datasite runs at significant scale across the M&A lifecycle and is a MongoDB customer.
• Engineers cover sharding, performance, and applying AI to the Datasite platform.

Rare technical depth on the engineering behind Datasite, reassuring for scale- and security-conscious buyers.

Hi, my name is Heather Lutz.

I am a manager at Datasite for data and data integrations, and this is the MongoDB podcast.

Welcome to the show.

My name is Shane McAllister, and this is the MongoDB podcast.

As ever, we're grateful to have you tune in to yet another episode of the MongoDB podcast.

And in this episode, Mike Lynn talks to Heather and Michael from Datasite.

is a platform for mergers and acquisitions, and has been a MongoDB customer for six years or so, starting with on-site or on-premise, but recently moved to MongoDB Atlas, our developer data platform in the cloud.

In their conversation, we learn all about the scale at which data site operates, with over 40 terabytes of data stored in Atlas in the U.

S.

alone, and much more throughout the rest of the world, and what drew them first to MongoDB, , and we go in depth into details such as sharding and their plans around applying AI to the DataSite system.

Well, Michael, Heather, welcome to the show.

It's great to have you on the podcast.

How are you both doing today?

Wonderful.

Doing great.

Yeah, it's great to have you on the show.

And today we're going to be talking about DataSite and kind of the journey that DataSite has been on.

We'll do that through the lens of your own personal experiences at DataSite.

.

.

It's been quite a journey since then.

We've gone from managing all of our MongoDB databases and clusters on site, having some trial and error discussions on how to set up and architect it.

And now we have since converted to Atlas.

We're running currently, I believe, 15 clusters between our regional and global nodes.

And we are spinning up more all the time.

Let us as a company expand extremely quickly.

Oh, that's great.

And we're going to get into what Datasite does as a company.

But before we do that, Michael, tell the folks a little bit about yourself.

Sure.

So I started with Datasite just about three years ago, coming up on three years.

I started as a senior engineer.

My role today is around technology enablement, which is a somewhat newer paradigm.

Essentially, it's the concept of taking from end to end, focusing on not just technology, but processes, operations, people, training, user experience, all of the various components of a cohesive situation, basically.

And then working with the teams that own that functionality or those processes of that to come together and arrive at a solution that works best for everyone.

And so I have done, I've been on a lot of very interesting projects, especially this year.

.

You know, some of it is around data architecture.

Some of it was the bulk of the solution was just talking to people and getting everybody on board.

I mean, you know, really the focus is our myriad in the technology enablement space.

That sounds like a really interesting and varied role.

I love that.

So let's talk a little bit about Datasite and what it does.

What does Datasite do as a company?

So Datasite develops, it has a platform.

.

I know we started out with products initially.

We are now a platform that facilitates the mergers and acquisition lifecycle.

So if you are a company and you're trying to sell your company, you're trying to buy a company, you are just doing initial research on who to sell or buy, and closing a deal and storing the documents, that is our focus today.

Where we started, and Heather can talk more about this, was primarily around the concept of a file room.

, folks would allow or set up a room in their office and just dump an insane amount of boxes of files in there and then allow the other party to go in for a certain amount of time and review them and look up things that cause concern for the transaction, that kind of stuff.

Our first entry into this was focused around digitizing that file room, adding in protections, eventually adding in redaction and now AI-assisted redaction.

.

And then as we kind of grew into more components of the lifecycle, that one was focused primarily on the seller side.

We then moved into a variety of other lifecycles, including the buy side, and started adding new what we're calling capabilities, which are, you know, we have a spreadsheet-like functionality on the site that's digitized, kind of like Google Sheets, but with some very M&A-specific functionality in place.

You know, started adding in other things, , allowing them to granularly manipulate the permissions on content, on features, that kind of thing.

We have another capability where they're able to email things directly into the project and gets processed, and you can review them and that kind of thing, or to send bulk emails out to potential sellers.

So there's a variety of different components within the platform that we support, and the list is ever-growing.

.

Security would be massively important in that type of environment.

I'm curious about the data schema.

Here you've got a whole variety of document types and data contained within each of those documents.

Who knows what the data elements are going to be?

I understand, Heather, you had quite an important role in the initial layout, in the initial schema creation.

Do you want to talk about how you went about looking at the possible data types and maybe even talk about .

Yeah, we can certainly go into some of that discussion.

So I mean, one of the advantages that we did have coming into this project as a greenfield was this was a rebuild of a current project.

So we can say we don't know exactly what they're going to be uploading, but we had a pretty good sense of what that metadata was going to be as we built out the schema.

So you know, for certain, every document is going, it's going to have some kind of data type, it's going to have a certain number of pages in it.

I mean, that's just, is what a document is and what is contained in there.

So that information fell in a fairly flat field that was very easy to query.

And then we thought, well, in addition to the basic metadata around the document itself, what else is going to be fetched in the vast majority of queries as we look at the usage in the application?

So then one of the items we thought of as well, access.

Access was another one that at the time we ended up landing in there.

.

When you load the page, we want to know, okay, you have access to which of these metadata, which documents, what can you see?

What can you download?

What can you actually print?

So that ended up being basically a nested series of fields and arrays within that document because that ends up getting fetched in with almost every query because we need to know if you have access.

That's something that we are starting to shift now as our use cases have grown potentially.

.

So those were some of those thoughts coming out the gate.

We also ended up putting processing stages in there as well to know that when a document is finished processing, is it still in the process of uploading?

Did it fail?

Was also another one that was kind of important to know.

It's all fresh at the same time.

So I'm imagining this file room and going from the physical world to the digital world.

These documents are scanned in some way.

Yes.

Is there a physical, of the data site platform, you know, the scanning, for example, or you just basically work with whatever scanning infrastructure is in place.

They would upload their digital content.

We don't have a concept.

Oh, I see.

Scanning in documents.

Okay.

So there's no longer a physical room.

The customers of data site come to you with.

Correct.

Electronic media.

In the application.

Yep.

Okay.

And that's probably PDF or images.

So I'm imagining, I'm imagining.

At least seriously anything.

Video.

F word document.

.

We have cell document.

We have videos.

We have watermarking on videos.

We have transcriptions of videos, right?

Yeah.

So the transcriptions would be good content to store in MongoDB.

But the blob storage, I imagine you're using some type of object storage for that?

Correct.

You got an Azure blob back there.

Okay.

And then there's some linkages stored in the database.

Correct.

Okay.

Yeah.

So why MongoDB?

Well, first of all, it does help that MongoDB was very helpful and supportive, days as we set this up.

So that actually was one of the considerations in picking MongoDB was how much support the actual organization offers.

Additionally, the application loans well to Mongo.

We have, we're mostly read heavy, to be honest.

I mean, if you think about the flow and what would happen in like an M&A transaction, at the very beginning, yes, you're going to be doing a lot of uploading of documents.

You're going to be setting up that file room, moving things around, setting it.

.

.

That and Mongo's ability to scale was another one, especially as we grow and not necessarily knowing what a user is going to end up doing with their project and their entry into a data site is extremely helpful.

So those were, from a data standpoint, technical standpoint, some of the reasons that we ended up going down the route with MongoDB.

Yeah.

And I, you know, at the core of it, right, Mongo is great for managing .

And so it lends itself very well to our use case, both in what Heather has pointed out, but also we are predominantly an event-driven architecture.

And so what that lends itself to is, you know, if we have a source of record and then we have, you know, a reference to that within another collection that is set up for pre-processed data for reads, we have events driving those updates to keep them eventually consistent.

is within a second or two, right?

Yep.

And that's defined within this system.

Right.

So it lends itself very well to that.

It's also very easy for engineers to understand, right?

We're predominantly restful services interacting with each other, right?

So the payload is also what's in the data store.

It seems to be a very ergonomic approach at persistence.

Tell me about that.

What do you mean by ergonomic?

.

We are training our engineers to be full stack owners, right?

You as a team, similar to the Spotify model, but a little different.

But you as a team own front-end services, back-end event store, your operational performance, that kind of thing.

But a lot of our engineers at their core are Java or Node engineers, right?

They know their service very well.

They're used to consuming client payloads.

They're used to publishing those payloads.

They're used to interacting with data in a very JSON-y, .

And so BSON is easy for them to understand, especially with a lot of the functionality in Spring Data Mongo.

You're interacting with things kind of similar to how you would be walking the graph of JSON notes.

And so it just seems to fit in place for a lot of microservice engineers.

Yeah.

I would also say just being on Mongo in general really changes kind of your engineering organization.

databases managed with a team of DBAs, an army of data experts.

Not to say that you don't need that with Mongo, you certainly do, but you don't need a full-time staff of DBAs to run this.

Your engineers have to take on the responsibility of maintaining and understanding their own data and their own data flows.

Sounds like a perfect match.

with maintaining our versioning in Atlas, with monitoring the macro performance of our systems.

We still need our engineers to be very fluent in Mongo because they own the data.

They own the data architecture that, you know, it's a different data modeling process involved with this.

And so we, you know, Mongo, the Mongo group has been really excellent with offering training, giving us the tools that we need.

I think we've got like a seminar coming up to walk everybody through it for more.

So, so that, that, It's very important to us that as engineers across, they're very comfortable in the Mongo space.

Can we talk a little bit about scale?

Now, Heather, you've seen this from the very beginning.

What are we talking about in terms of the number of the amount of storage and the number?

You said 15 clusters, but how much data are we talking about?

Give me one moment.

I did actually put this up because I knew you were going to ask me this question.

Well, you said we scaled.

We do scale.

Of course, I'm not in the right spot.

But I can tell you overall, .

So I do have some of these numbers memorized.

So including data that has gone through our system in total.

So to get an idea of what has landed from Mongo into our warehouses, you're looking at approximately 40 terabytes of data since we started, just in the United States alone.

Which for something that really hasn't been live for too terribly long in the grand scheme of things, that's a decent amount.

Yeah.

And to give you an idea, we also have other regions.

We have regions in Europe.

We have regions in Australia.

We're pretty wide.

So that's just US.

And Europe, I think, has been more active, at least recently, even than US.

So 40 terabytes, that's a lot of data.

How many documents do you think make up the total 40 terabytes?

When you say documents, do you mean Mongo documents or do you mean...

Yeah.

Well, actually, yeah, let's go from the physical world to the digital world.

How does it translate from physical documents to that 40 terabytes of data?

Well, I would say, The 15 clusters are separating data amongst their concerns.

So we obviously don't just store documents.

We have, I don't know, a couple hundred different collections across the clusters with different varying data.

Yeah.

And the size of those collections range a good deal.

I mean, we have some collections that have a few hundred documents in them.

We have documents with shards that have 19 million in them.

So that's, I mean, they range a good bit.

data.

.

So when we were actually setting up Mongo, even when we had it on site, we were planning on making that sharded.

We had chosen a shard key and knew how we were going to do that as we set this.

And as soon as we started seeing issues in performance in that particular cluster in Atlas, we were able to turn over that into a sharded collection, I'd say within a few hours.

Yeah.

And part of that is the administration.

.

How did you go about picking that shard key?

I mean, that's incredibly important out of the gate because, well, up until recently, it was impossible to change that shard key.

So how did you land on the specific piece of metadata you used for the shard key?

For us, this actually wasn't that big of a decision, shockingly.

.

Every single client we have, the entity that they are uploading their documents in, that they are asking questions in for Q&A, that they're redacting in, is a project.

That is the bounded context that every single client has.

And everything is limited by what is in that project.

Project sits in a lot of our APIs.

Those APIs show up in a number of our databases.

is a common foreign key.

It made so much sense to use it as our shard key as well.

I will, but we might be having discussions about that in the next week or so based on what we're currently looking at.

So we're in a phase right now.

We've grown pretty big.

We're now seeing far down the road potential issues with scalability.

And so we're evaluating our systems and making sure that we are structured correctly to scale in the directions that we're seeing the business going.

.

And so we're in conversations with that to offer...

It just offers our platform a vastly more flexible...

There will always be a context, though.

And there will always be a project context.

There just may be other...

Yeah, we are expanding.

When we first started this venture, we had the original M&A application, and it was the only product we offered.

I built that up from a green field.

And I remember constantly being told, just build it like it was in the old product.

Just build it like it was in the old product.

Because we had this fuzzy concept of what we could potentially do.

We knew that there was more to the M&A process other than diligence.

But it was very early days and we had nothing concrete.

So we were able to build it up knowing we were going in a certain direction.

And that model lasted us a good six years.

Well, I love the foresight.

.

So what's next for DataCite?

What's on the horizon in terms of projects or platform expansion?

Well, so kind of leading with that scaling thing right now, that is the primary focus of my position is working with teams to identify those challenge areas and coming up with a short, medium, long-term plan to adjust them.

We recently just completely revamped our, you know, our blob replication system, right?

Ensuring that we just partially for disaster recovery, but also for, you know, not quite edge computing, but, you know, bringing our data closer to compute.

And we're also running into scalability issues there with how it was currently designed.

So that's one that we are wrapping up this quarter.

And so far it's looking excellent.

One we're currently in, both Heather and I, is a pretty interesting challenge.

is dealing with, I mentioned before that we offer redaction AI.

In other words, AI assisted redaction suggestions.

In other words, you know, you load a bunch of documents in, we know specific categories that you're going to be looking for, like PII, like money, you know, those kinds of things.

It runs through our AI engine and we produce a ton of suggestions for you for each document, you know, where the suggestion is to be redacted, what type it is, the value, .

So when you go in, you don't have to individually redact all the different components.

Can I interrupt you?

So is that redaction in the image, in the PDF, for example, in the blob, or is that redaction of the fields within the MongoDB document?

In the PDF.

We don't store, our redaction process is pretty cool.

You can't, it is actually redacted from the PDF that you have access to.

You cannot access.

Yes.

Very cool.

tends to be more, okay, what was the field that was redacted and where in the PDF does it exist?

Oh, very cool.

Very cool.

And then that's rendered on the client side, that component, most of it.

Anyway, so with AI, of course, there's a ton of data that comes into play.

And the graph of how this data is persisted and then accessed is unique in my experience, really.

the life cycle of a project, folks will dump tons of documents into our system, upload, I mean, just an insane amount of documents.

And so as you can imagine with AI, there's a little bit of time that takes to flow.

And so we process those suggestions at the point of upload.

Once we upload them, process them into, you know, understandable readable formats, we then run through those suggestions.

Those suggestions then sit for months sometimes.

.

And so effectively, you have this graph or this access strategy where you have write-heavy, super, super heavy, and then it just sits.

And then now we need access to it.

But most of the time, they need access to just aggregations on that data.

And so we're looking at different solutions potentially involving Mongo Archive, other areas where we have this concept of cold storage .

I guess save some money by moving some of the older, less frequently accessed.

Yeah, correct.

Yeah, okay.

Are you using Atlas Search?

Not yet.

Okay.

There's been some initiatives recently where leveraging that with the leucine index seems to be something to vet, at least.

Yeah, there's definitely some thought around it and some curiosity.

Are you maintaining your own elastic instance separately?

.

How are you doing search through the documents?

Yeah, this is definitely Elasticsearch.

So it's maintained by us.

Okay, so it would make sense at some point to, okay.

It very well may.

But we've had Elasticsearch for a while.

I mean, it's spun up as one of the initial things we released with.

So it's one of those items where if we did decide to go down the route of Atlas search, it would take us a bit to deprecate and move over slightly.

Yeah, for sure.

Okay, so it sounds like you've both got your with some amazing projects.

I'm curious about how you stay current with all of the things that you need to know to continue to be effective in your roles.

I always like to ask folks, are you listening to other podcasts or are you reading books?

Michael, what's on your reading list?

So very appropriate for where we're at.

About a month ago, I just finished New to Big, which is just great use cases in that of companies that started out at a certain point.

They're at a growth point.

where now they need to set up to be scalable across.

And what does that look like?

I read a lot of architectural documents across a variety of different concerns.

In fact, I was just vetting data architecture for MMORPGs, right?

Because that's a fascinating area.

You know, I'm kind of, I was recently just kind of dusting off some books of mine on Lambda architecture, which seems to fit some of our use cases, right?

We know the query, it's going to be .

I read heavy.

It's okay to be eventually consistent, that kind of thing.

A lot of technical documentation.

And frankly, talking with folks like Heather and some of our other very, very senior engineers because they all have passions in different areas.

And it's always great to learn from other folks.

Yeah, for sure.

Heather, what's on your reading list or even listening?

Are you listening to podcasts or anything?

I literally just pulled my work bag out and like, which book do I have in there right now?

.

Designing data-intensive applications.

Oh, very cool.

Yeah.

So that's actually one of the books that I'm actively reading.

I'm calling it my lunch break book.

So when I actually hit lunch, that's typically what I'm doing is I'm reading.

The other item that I've been kind of going through recently is the idea of data mesh.

Reading through some of the blog articles on that as we start looking into...

So from an engineering organization perspective, we've spent a lot of time working on...

.

We were looking at domain ownership and making certain that teams have ownership all the way from the front end of the applications down to their data stack.

And I'm now starting to get into this question of, well, from a data level, how do we make it so that teams have the resources and ability to own their data from start to finish?

I mean, with Mongo, they kind of have to own their data on the Mongo side because it's introduced in their code.

is essentially what's sitting in your entity.

You have full control over it.

But once it's in Mongo, do you own all the pipelines?

Do you own the event-driven pipelines that could potentially be communicating your data outward?

Do you own your analytics data?

And how does that change how your team functions?

Who is on your team?

And what insights does that give you?

Being able to have access to that data, , have an idea of what your clients are doing within your domain really can drive a lot of your decisions.

Yeah.

And I would, just for additional context there, so that when we talk about these capabilities, we started out with different products, right?

Diligence for the sell side, acquire for the buy side, prepare.

And each of these were monolithic things with domain services underneath.

We have since switched to kind of become that platform as a service piece.

Each of these capabilities, , like trackers or your documents structure and how you interact with it from the front end all the way down.

We're migrating those to be essentially like individual companies to where even internally, we're interacting with them like they're third-party services.

And kind of that loosely coupled, highly aligned, I think, is our CTO's favorite line.

And that's really, truly what we're trying to build here.

So with Heather, Heather is taking it even further than we have it right now, .

So already each capability team owns their CICD, owns their testing, owns their user experience, owns the front end, the back end, everything.

But now bringing it down to the data analytics level is really going to offer us a lot of power in that they know how everything is being used and they know what they're exposing out to analytics.

So what important things do the listeners need to know about DataSite?

We're moving fast.

.

to me is, I don't know if you know, but that auto stop in cars, that actually came from biology, from locusts.

They watched how locusts change direction in that and they figured, they honed in on what is the actual mechanism that allows, that supports that kind of quick reaction.

And that is what's facilitated auto assist or auto break in cars.

So something from biology can affect automobiles.

I always thought that was fascinating.

Yeah.

Yes.

I've got some Googling to do.

.

That is fantastic.

I love the sources of inspiration for technologists.

I mean, it's really when you look deeply, they're all around us.

And I think it's about getting creative.

So what's the culture like at DataSite?

Inquisitive.

Yeah.

We definitely like challenging ourselves in the best possible ways.

We have some great and interesting problems to try and solve.

As a manager, I get to sit in a number of interviews.

.

This is not part of my job description.

And I talk to people all the time, yeah, it's an M&A application.

It's way more interesting that it actually sounds from a technical standpoint.

I have a lot of people hesitant when they come into some of my interviews and they're like, well, what is this actually like?

And it's like, no, you actually do get to handle some pretty complex problems, like the redaction problem that Michael Merlin was mentioning earlier.

We're just starting to introduce to our system and getting that to move data around, introducing the Mongo streams, connecting it to Kafka and starting to move that data, persist that data in flight.

And you're talking about potentially using like your event source as a source of truth for certain parts of your data.

There's a lot of very exciting things happening under the covers with this platform, especially from a data standpoint.

And from a culture perspective, we have tremendous leadership.

They really go out of their way to make sure has a sense of agency.

You can control what you want to.

The group that I'm heading right now, this technology enablement piece, we're not a bunch of ivory tower architects demanding on how you do this.

This was a situation that was engendered by our leadership, which was our team will go and work with folks.

Yes, we'll offer some architectural options.

We're not going to ram it down their throats.

.

We're just going to kind of facilitate the conversation and make sure that all aspects of the challenge are considered.

Yeah.

It's not just giving a suggestion.

A lot of times we will give like a workable solution.

Right.

If it works for you, wonderful.

If it doesn't, feel free to expand on that or use a different use case.

So there's a lot of flexibility there.

But that is kind of part and parcel of our culture.

We always try to make sure that the easy path is the right path.

.

You are, feel free to go off that path and do what you need to do, right?

As long as you have safe architecture and you're doing things in a way consistent with our requirements or our priorities, that's completely fine.

We are of the polyglot, right?

So we have node services, we have Python, we have, you know, whatever people want to get into is fine with them.

Then we make sure that they have the tools and the education and, you know, to go down the path that they want to.

Yeah.

I'd say the other thing that really is also helpful and kind of unique is back to that curiosity that we really do inspire, encourage innovation within a site, especially from a technical standpoint.

But even beyond that, this organization does two, I'm going to call them hackathons or so in a given year.

And these are open to anybody in New York.

So yes, it's great when you're working with your team on a project.

.

in our actual application.

A lot, actually.

I would say a handful every time we do an Innovation Jam becomes something we want to get prioritized through the product, through everything, and get implemented.

This is not just a playtime for engineers.

They actually put power behind that.

It's a great way to introduce product in the org to ideas that may not have been readily apparent.

That big Kafka effort that my team is working on right now, that's .

The new, we just revamped our permission system, took about a year.

I POC'd that for one of our innovation jams.

Ditto the whole capability thing that we're now driving our platform towards was also part of this.

I love that.

I guess I think that was the one we did together.

The capability one, yeah.

That's awesome.

We do something similar at MongoDB.

We call it Skunk Works, and there have been several products that have actually been launched and born of the Skunk Works hackathon , so fantastic.

That's great.

Heather, I did have a question.

Now, you talked about starting at Datasite as a young engineer, and now you're talking about being in a people leadership role.

Tell me about that transition.

Has that been difficult for you?

A little bit.

I'm at the point in my career where I have fallen in love with technology, and I would just love to spend all of my days tinkering with all of the things.

But at the same time, I'm very interested, as Mike said, making certain that folks have the tools that they need to keep innovating and moving forward and inspiring others to kind of keep building in new directions.

I originally started as, like I said, a junior engineer.

I kind of got my feet wet.

And then I'd say within a year, I was like, you know, I would really like to see this done.

And I started having all of these suggestions.

And then my manager at the time said, do you want to be the dev lead?

I was like, what?

I don't even think I was a senior engineer yet and he asked me that question so I mean I just I always have ideas there's always something percolating in my mind and my thought has always been the more ideas that we can bring into the forefront the more thoughts that we can bring into a POC into an MVP the better this product is probably going to turn out because you never know who has the idea for your next big product .

Yeah.

Well, I've really enjoyed our time together.

We're running up on the time.

I did want to ask you if you had any advice or suggestions for folks considering a deployment with MongoDB.

Are there things that you've thought about since you've gone live or migrated to Atlas?

Things you'd like to share with other folks listening?

I'm sure you have a bunch, Heather.

I would say that making a shift from a traditional SQL solution to a document store has a lot more to do with with the culture than it does the actual technology.

I think if you can make that cultural shift correctly, then you have a tremendous, you dramatically increase your level of success, right?

If you just introduce the technology and folks interact with it like a SQL store, it's not designed for that.

It'll work.

But to unleash the true power of this technology, you really need to have that paradigm shift in the engineer's minds.

Yeah.

And making certain that you know why and these engineers understand why this is the right tool for what you're trying to accomplish.

There's a lot of ways that you can move a ball forward.

There's a lot of technologies out there.

But making certain that everybody understands and has the education around Mongo and knowing that, yes, this is the right path, this is the right way forward, it does make that transition a lot easier.

.

And making certain everybody is trained, that's a great one.

I still have some absolutely wonderful memories, some of them fairly recent, of sitting in workshops and learning about MongoDB and sitting with other engineers and trying new things, trying some of the new features that have been released.

It is always a lot of fun.

Mongo is a lot more hands-on for engineers than a lot of other database technologies, and it is an absolute best.

Yeah, Mongo University was part of my onboarding.

I had done no sequel before, but was new to Mongo and I fell in love like instantly.

It's so much fun.

I still, you know, migration scripts are one of my favorite things to do.

I love it.

All right.

Well, Michael, Heather, thank you so much for spending time with me.

I've really enjoyed our chat.

Thank you.

Anything else you'd like to share with the audience before we wrap up?

Not that I can think of.

Thank you.

I really appreciate it.

This was excellent.

Thank you very much.

Thank you.

is that this time of year is MongoDB.

at DotLocal time?

That's right.

We're bringing the best of MongoDB world on tour, hopefully to a city near you.

At DotLocal is a day filled with educational breakout sessions, announcement-packed keynote presentations, customer stories, and free one-on-one Ask the Experts consulting sessions, along with networking opportunities and much more.

We've just completed Frankfurt at the end of September, but in October, November, and December, we will bring our DotLocal event to San Francisco, .

for me, Shane McAllister.

Until next time, do take care and thanks for listening.