From Legacy to AI-Ready: How MongoDB AMP Accelerates Modernization

Retool gives you a way to break that cycle. Their platform lets people build custom apps on your company data while keeping it all secure. Type a prompt like build me a self-service reporting tool that lets teams query customer metrics from Databricks, and they get a production ready app with the permissions and governance built in. They can self serve, and you get your time back. It's data democratization without the chaos.

Check out Retool at dataengineeringpodcast.com slash Retool today, that's r e t o o l, and see how other data teams are scaling self-service. Because let's be honest, we all need to retool how we handle data requests. Your host is Tobias Macey, and today I'm interviewing Shilpa Kolhar about using MongoDB as the foundation for AI driven applications. So, Shilpa, can you start by introducing yourself?

And we also built ML Data Store, which was the back end that had all of the pretraining data for both classic ML and also for Gemini and

Gen AI use case. So it felt like I spent nineteen and a half years working on scaling the data infrastructure, working on making data available for different use cases, be it ads for monetization, building products from zero to 100 with display ads, remarketing, Gmail ads, and so on, and also handling data with a lot of love and giving utmost importance to data safety.

And that experience of mine actually led me to MongoDB, my current role, where where I would like to bring that scale and that that rigor to every developer and the community that, you know, has leveraged MongoDB for their applications and are working towards building their next generation of AI applications and AI agents on top of a solid unified data platform like MongoDB.

because it's a data model change. You know, when we move from tables to collections to document model that MongoDB is built on, it's it's a data model change. It's rewriting or, you know, I'd say, transformation as well. Like, you know, you analyze the application, do the code transformation, the data modeling schema changes, and then finally, you know, getting it to be deployed so that the customers are able to leverage

MongoDB as their data back end. So our goal is to get customers onto MongoDB, be AI ready. You know, it's not just about, like, okay. Take it one is to one, convert the functionality assets, but bring in the good practices and good design patterns that we have seen more recently onto these applications that have been modernized.

The cost was a major factor. But now if you are if your data and your business logic is is stuck in the legacy system, then you are not able to leverage, the new agentic AI enabled features. You cannot build that easily on top of these stacks. So I have seen that as the driving factor, but, you know, cost is still one of the driving factors and for modernization. So it's not like it's gone. That's still there. And with AMP, we are working on actually, you know, the speed to modernization.

That's our top goal instead of the the traditional way that SIS two where they take years to solve the modernization problem. We are looking at an order of weeks to months to actually do projects which would have otherwise taken two to three years. Now your other question on, okay, know, when we are modernizing when we modernize on MongoDB onto MongoDB, that natively gives the application

ability to change much faster because the data model at the DB layer and the data model at the application layer is the same. So if you have a user profile that you are working on that the application layer is working on or the agent is looking at it, it's the same user profile that's also stored in the DB. So any changes to this is much faster. So natively, MongoDB supports change much faster with lesser technical debt. And that helps

not just through the modernization process, but also once you modernize, you are, like, better equipped with change. And and in this AI world today, we know that the one who can change fast is the one who will succeed. So, you know, that way, the native JSON document model, which helps with faster changes, has been a critical

motivating factor for many of our customers. And then the other thing that recently not recently, last year acquired YJI with, you know, world class, best in the world embedding models.

And now we are looking at data not just as operational data. Right? It's the it's operational data, contextual data, having search built on top of it, the right embeddings on top of it where, you know, there could be multimodal data mixed in together, which will then enable your new agent AI applications that you could build on top of it.

And I'm wondering if you can talk to some of the aspects of MongoDB and their implementation and how they compare to that broader ecosystem of the investment that's happening where you have things like Quadrant that is purpose built for vector storage and retrieval. You have Weavier, ChromaDB, Pinecone, I think, was one of the forerunners there that even predated the introduction of ChatGPT.

I'm just wondering if you can talk to the primitives in MongoDB that allow it to be competitive in that ecosystem.

relevant, and real time in sync with the data. So the the drift that would have otherwise happened if you let's say, you have here is your source of truth, your database for your source of truth, and then here is your VectorDB where you move the data from there to the VectorDB.

And then you have, you know, embeddings and search on top of it. There is this Drift aspect that naturally comes in with having two different data source, which gets completely eliminated with MongoDB providing that unified platform. Also, terms of, you know, security and access patterns. So, like, all the standard issues that you see where, you know, copying of the data or duplicating of the data, even though that data is in the form of embeddings. Like, you know,

the same issues would happen if there is a separation. Now with MongoDB's unified platform, you get it all together with a very low latency, which is very critical for any AI application. And, also, it makes it as a a good use case for maintaining your contextual memory because, you know, it's a real time transactional and so on. You know, if we look at Retool, Retool recently, it named MongoDB's Atlas Vector Search as the most loved and the second most adopted VectorDB in the market.

And, you know, this is helping deliver high quality retrieval and with a greater accuracy that modern AI and Rag applications require.

That can also end up being counterproductive if you're not careful because you need to make sure that whatever attribute you're trying to retrieve actually exists or that the data structure that you're trying to operate on has all of the pieces that you think it should because maybe you wrote a document six months or two years ago, and then your schema in the application evolved to add or remove various fields and features.

And I'm just wondering how you've seen teams address that Drift in terms of that schema at the application layer and some of the functionality that Mongo offers to maintain that level of consistency and avoid errors and failure modes due to that lack of oversight or due to the accrual of technical debt?

You can tell the database, look. I don't care about what else is in this document, but every document every user document, for example, should have a valid email string and should have a creation date.

And you can even set it to like, you know, you can call it to be a strict constraint, or it could be a warning instead of a reject. And that way, when at the ingestion time itself, because of this JSON schema validation in place, you can eliminate some rows which don't fit in that specific schema to avoid future schema incompatibilities.

The flexibility that I love here is, like, you know, you you can decide to won or reject or accept it. Now, you know, based on your use case, you can pick whichever which of of these constraints is, like, appropriate for you. And then the next thing that I love is the schema versioning.

Like you said, you know, there is a change in the application layer or there is a change in the in the database schema over a period of time, then how do we handle it? And the way, you know, developers or application developers who have used MongoDB have handled it is with you're leveraging the schema versioning pattern. So instead of trying to keep all the documents in the collection in sync and doing this huge data migration or, you know, data updates at a time, we have this notion of schema version. And so that way,

at the application layer, it the application layer can be schema aware. Like, you know, if you pulled a data or a document of v one record or v one version of it, then this is what the content of it would be. And for v two, it could be a different content. And then the so that way, the application level, you can handle the schema variation, which gives you time to heal the DB or you have to to get all of the datasets to be following the same scheme or the same pattern.

And then we also have these, you know, constructs or parameters. Like, you know, we we have aggregation pipeline. So at the exit, when when the data is red, you can use constructs like, you know, add fields. If a field is missing, like dollar add fields where you can set those fields with the default value for the documents which do not have those values. So that way, the application layer always sees a consistent

view or the schema of the DB. Like, missing fields, nulls can be handled very well with these dollar add fields. And then last but not the least, you know, the at the application layer, you can always handle it through ODM, like Mongoose or Node. Js, where they could potentially be that layer where, you know, it defines or prevents the schema drift impacting the application.

And I'm wondering how you're seeing in the context of that application modernization platform, the leveraging of JSON Schema as that shared representation across the different process boundaries and being able to do cogeneration and accelerate the delivery of new clients and new functionality because you have that standard representation that can be used across different language boundaries.

not just at the DB layer, but, you know, at the interface level, at the API level, the way the data is exchanged. The way we are handling application modernization where we actually, you know, do the analysis of the application, analysis of the DB, both runtime and static, you know, leveraging logs and so on, are one of our initial deliverable or milestone or phase is to come up with the right schema recommendation

and then have that JSON representation at the DB layer. And this schema or the recommended schema is then a critical input for all of our agents that are doing the code conversion.

And we have you know, like, naturally, like, as you said, you know, with the the application development, the API interface tended to be the same JSON as that of the DB layer, especially when people are looking at, you know, data transfer between the application layer and the DB layer and also between the APIs, between the microservices as well.

But oftentimes, each of those services will have their own persistence layer, maybe not even the same persistence layer where maybe a Postgres in one place, Mongo in another, s three and a third,

another one just uses Kafka queues. And I'm just wondering if you can talk to some of the ways that teams who you're engaging with think about the standardization on Mongo as a means of reducing complexity and reducing cognitive overhead of teams who are maybe working across boundaries of those different services?

And that happened naturally because of various acquisitions as well. So it's not just a legacy enterprise customers issue, but even, you know, more recent recent companies, like, which were born in twenty tens and later have have this issue of, you know, n different data stores, not by design, but because of acquisition or, you know, some such path that they followed.

So the way we are when we talk to the customers for application modernization, when we look at it from our point of view, we look at the whole code base, the various databases that exist, and the and, of course, their schemas and so on. And looking from the outward and, like, you know, looking at the business goals, we come up with modernization units.

Now, yes, I have also seen in the past, you know, you can go too much into microservices where making your actually, you know, it could end up with your whole ecosystem being extremely complex. Because, you know, there there is a pro and con for going way building too many smaller microservices. So having the right balance is important, and the way we are tackling it is like, okay. Creating modernization units upfront.

So there would be a modernization unit. Let's say if it was a retail company, a modernization unit whose whole and sole purpose is to handle product catalog. And then there would be a modernization unit whose sole purpose of that exercise would be, you know, order and delivery. So we take one modernization unit at a time, look at the various data back ends that was used in that modernization unit, and then go from there by migrating it onto like, modernizing it onto MongoDB.

And MongoDB does provide you know, it's it's your operational database. And, you know, if you want to store your activity data, MongoDB already supports that. If the modernization unit, you know, needs at some point a chatbot, yes, we have the rag built on top, vector search built on top. So that way, you know, one modernization unit at a time, holistically, we move the data from various sources onto MongoDB

as we rewrite that application for them. Of course, still retaining all the, you know, the governance and security needs of those applications.

evolution where maybe they have a certain mindset of this is how you build things. They've got their set of patterns that they're used to and just some of the overall workflow of being able to get teams up to speed with how to use a platform like Mongo AMP idiomatically and not fall back into their old patterns that caused them to try and do backflips to do something that is actually just two lines of code, and they're actually writing 200 lines of extraneous code unnecessarily.

Because even before we do the analysis, when we have the initial discussion on, like, okay. What does your application look like? You know, what do you think are the dependencies? When we create that sheet and then we go back, do the analysis, and see what we unearthed and what we found, it's just amazing to see the reaction that the customers have. They're like, okay. We didn't know that we had,

you know, 500 stored procedures in our Oracle DB. Okay. Or we didn't know that, oh, not only we used or we didn't know that our application dependent on was dependent on this another Qubal application. You know, there are a lot of surprises. And many of the things that they depend on,

you know, were probably end of life, like, a decade ago, and it's still running. And I think that was the biggest surprise that customers had when they first engaged with us and then when we gave our initial report to them on their application, their code base, and so on. So, yes, I think, like, not doing the scope of the scope of the modernization project is is the

initial biggest surprise that the customers have. Once we define the scope, I think, yes, there are there is always a push and pull in the in these, you know, large companies where things evolve based on the org structure and team structure, which might not necessarily be the right design or approach that one needs to take in their new

modernized application or whatever is relevant today. So there are some frictions there where people would be like, yes. You know, I want this to be a separate service or, you know, because the team is structured along those ways. So that that's why we have our, like, MongoDB AMP has our team of engineers,

forward deployed engineers who work very closely with the customers to actually get them onboarded onto, okay, what would the new architecture look like? What would the and how could they, enable further development and STLC in this newly deployed application, right, in the with the new architecture. And we also you know, as part of AMP, it's not just the, you know, the platform that we bring in. These

people are working with techniques that we have developed over and over again with multiple different engagements. So the process management, educating the customers, and then bringing them up to speed on how to maintain the new application is something that we have worked on over the last two years.

reflects that. In fact, it's vice versa. Actually, application layer actually works on, like, let's say, a user profile as an object, like, with all the properties of the user profile in there, then our data layer actually reflects that.

The other patterns that we are, you know, recommending at the application layer, of course, you know, no need to reinvent the wheel. Let's look at the applications being rewritten using Java SpringBoard framework, and we are asking them to standardize on, you know, logging, standardize on authentication, and so on. But not all customers want to change some of these aspects, and we are okay with it. We have that customizations in place for them in case, you know, they

like, they are doing one modernization unit at a time. They cannot be drastically changing their CICD or STLC for that specific unit, we will nudge them towards a direction. But once we finish majority of the modernization unit, that's when that change will happen.

through the execution of that application. And I'm wondering how you're seeing teams leverage some of the primitives of MongoDB to be able to power those use cases as well.

helps in MongoDB being positioned as a back end for context memory. Because the critical thing, you know, as the agent is running, you cannot wait for, okay, I'm gonna put in this context in the DB. Then now that is going to further get indexed, embedded, and then I'm going to look up. There's no time for it. Everything has to happen real time. And that's what MongoDB,

you know, is really good at. And with all of these functionalities, like, you know, embeddings, indexing, natively available in the same platform and and in the on the same dataset, It just makes it like a perfect fit to be both, you know, as a back end for short term and long term context memory that is needed for agents. And, also, the other aspect is, like, you know, today, we already support

various interactions or various events that happen. And now with agentic AI, you know, the the the number of these events and the not only it's the events that happened, but also reasoning associated with it and the context associated with it, which could be not necessarily structured, but it is semi structured. It naturally fits in the MongoDB's document model.

The most interesting thing in the context of AMP that I have seen, you know, MongoDB being used is not just as a destination database where, you know, you go onto the database with the modern app, you are ready for AI, but also how my team has been able to leverage MongoDB's features, like, you know, like the zeroth customers.

So as you as, you know, AMP is a platform which leverage which is built on top of, you know, agentic AI and the deterministic tool, we are able to leverage MongoDB to be that context memory through our application transformation. And

I'm super excited about it, where, you know, we can actually see things live in action. We are looking at exceptions that happened, errors that happened, bunch of text, which then needed needs to be added as context back to the build, you know, fix build test loop of ours. All of these context going back in into MongoDB to actually enable customers to move from elsewhere onto MongoDB. I just love that that cyclic

amplification that MongoDB is able to bring. And, you know, when I think about it, if I were to do modernization, MongoDB is, like, the perfect database because it naturally supports going an incremental path towards more modernization.

Otherwise, think of it. Like, you know, if you were to do it with a relational database, then I need to have my schema in place because making a change in the schema, change to the table, change to the columns is end to end all the way from the DB layer to the application layer and the UI layer maybe, in some cases, changes. But then MongoDB natively supports that incremental development, And that is the strength that it brings as the destination DB for AMP.

So that that helps my team to go one modernization unit at a time without having to rework the previous modernization unit when you work on the new modernization unit. And that's why I say that, you know, when you move to MongoDB with AMP, you are actually set for future. Hopefully, you'll not need any further modernization projects because now there is no accumulation of tech debt. You are naturally evolving, and your DB is evolving with you.

out of the box without having to do any work. I think there is a lot of noise and chaos around it saying that, okay, these are the capabilities without people realizing that it actually still needs a well thought out process, a well thought out end state architecture, and breaking that problem down into, you know, subtasks or subproblems, which, of course, the LLMs have helped us expedite amazingly. But then how do you leverage them at each step is is,

you know, is a is a learning for my team. It's a learning for our customers, you know, bringing them along saying that, okay. It's a magical bullet to like, here are the steps in word. And this is how we can leverage. Yes. It is still awesome. It'll give you you know, we have seen customers' codes transformation expedited by 60%, and we have seen customers being able to create new workflows and onboard customers reducing the onboarding time by 85%. So all of those success stories are amazing.

Still, this it's a step by step process. We need to work with I mean, build those right agents, give it the right context, and, of course, you know, leverage the awesome models that have been built to do this application transformation. It's not a magic bullet. And then the other thing that I'm I'm also noticing is that there's a lot of variations in the legacy code.

So it needs focus. So we got to pick, you know, few stacks to start with, build on top of it, and then LLNs will naturally help you, you know, extend it to other use cases as well. So this still needs that, you know, stepwise systematic approach to modernization. It's not just a model I mean, not just for modernization. I think any problem that we take, this notion of, okay, LLMs will solve all for you is is

something where I see a lot of people coming in. Like, okay. We could do this. Okay. We could do that. Yes. You can build prototypes. Yes. You can show some initial proof of concept. But when we are looking at enterprise scale and, in fact, you know, it's a business critical applications, you can't be taking that risks. We should leverage LLMs. We should leverage the deterministic tools, ensure that it is repeatable, and, you know, ensure that the the end application is secure.

Have the human in the loop for all the validation that needs to be done. And that's how we successfully transform an application, like a legacy application into a modern application that is ready for your next gen of customers or next gen of APIs and also your database or data platform being ready for your, you know, agent AI applications for future.

But if you ask me, like, okay, there is one place where, you know, it wouldn't I would consider something else. I think if customers are looking for a generic data back end for, you know, analytics. That's where I would say maybe there are other choices that should be considered.

moving the business logic from the data layer to the application layer, orchestrating all of it, having the right APIs and interfaces and so on. Today, it is done through, you know, a tool chain with technique involved, with people, experts who actually come and help the customers, you know, with some of the variations that one might have seen because of two, three decades of evolution of these legacy applications.

What I look forward to in future would be, you know, taking as many of these steps where there is human in the loop to convert it into, you know, multiple different agents which work together. Yes. There are certain steps where we will still need humans for, you know, governance checks and security approvals and so on, but there are many aspects that we are

looking at converting the steps that were earlier done with human in the loop by having multiple agents interact with each other, having an agent that does the critique of the steps that the previous agents took and so on. That is something that I'm looking forward to.

It's more about what is in that data, the meaning of that data. And database systems have been more about, like, you know, system of record. Like, here is an action that happened. They recorded what rather than why, and this change from what to why would be a big change for our data management overall. Right? You know? If an action was taken, then we, you know, we looked at it saying that, okay. This action was taken on this data. This you deducted $100 from this account,

and that that was it. And we had a version ID and said, okay. Previous version had $200. The next version has $100 deducted, and it's only $100. And that worked really well for us till now. But in the AI world, the application is not static. The agents are not static. They are also evolving and updating themselves. So just having noting down that, okay, there was this change. What change is not sufficient? We'll have to look at what changed,

why it changed, what was the reasoning behind it, and what was the context behind it. So a simple thing like versioning now becomes a complex problem. And something that was cheaper earlier, like, okay, just put a version number. Now you'll have to have all of the context around that. And, you know, earlier, you just needed to know what was the application's current binary release number because it's always deterministic, and now things are changing drastically. So so I think

simple problems like versioning will be will need to evolve. And then the scale at which we handle the data will need to evolve because now we are not we and the latency also the latency at which you read and write data also is evolving because we are not we're thinking, like, earlier, we'll be like, okay. Yeah. Human will interact with the application. It's okay for it to be in milliseconds

or seconds. But now, you know, with agents running your workload or taking the decisions for you or taking the action for you, I think that real timeness, the definition of how real time is real time is drastically changing. And I I believe that in all of the data stores and data management systems should should evolve to those needs.

Thank you for listening, and don't forget to check out our other shows. Podcast.net covers the Python language, its community, and the innovative ways it is being used. And the AI engineering podcast is your guide to the fast moving world of building AI systems.

Visit the site to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts at data engineering podcast dot com with your story. Just to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.