Greg Irwin 0:18

My name is Greg Irwin. I'm one of the partners at BWG. Moderate these types of forums for a living, we have a network of about 100 100 150,000 active participants. We're here co hosted today, with Stacy Scoggins, Stacy's field CTO and Enterprise DB, referred to it as EDB. And, and Karka Jegadeesan who's joining us from Platform 3. They're a premier solution provider around around poke Postgres SQL, and real experts here around around EDB. So, we have a couple of very simple goals today. One is let's learn from each other. If you're taking time out of your day, let's make this thing worth it. And then two, I'm asking for one, one personal goal, try and connect with one other person across this group, you'll see I'm gonna get everybody actively involved as best I can. And I'll encourage you, it's an outstanding group that's joining us here. So build out your personal networks. And and reach out to more than one another here. If you need some help come to the CRP BWG. Okay. Let's get right into it. And I'm going to ask Stacy take a moment and introduce EDB and organize Karka to take a minute and introduce Platform 3. Stacy up the mic? Sure. Yeah. So

Stacy Scoggins 1:49

good morning. Good afternoon to you guys. We're glad to be here just to kind of share our knowledge and expertise. And to give you a little bit of background about Enterprise DB or EDB. We're the world's premier provider of Postgres services support and subscriptions for Postgres. And we can say that we acquired a company two years ago, second quadrant, that was the second largest, right, so by that combination, it makes us you know, well introduces us to be the largest provider. If you think about it, and I don't know how familiar you guys are with Postgres. Hopefully you are. But I always use the analogy. For the uninitiated, if you think about what Red Hat did for Linux, right, they took this open source operating system, and really made it production ready by providing tooling, and subscriptions and support and services around this open source software. That's exactly what EDB does for Postgres, right, we provide everything that you need to take Postgres, this, this open source community project, and make it an enterprise ready database in your environment, we bring some unique capabilities on the table in our Oracle compatibility, right. So you can very quickly and easily with minimal, and I'm not gonna say zero effort, but minimal effort, move your Oracle estate over to our Advanced Server platform. And we work with partners like Platform 3, that Karka's with to bring those other database technologies into Postgres, as well, our tooling is specifically around Oracle. And we have migration capabilities to be able to do that quickly with tooling and other things that we bring to bear in a programmatic manner. But Pat, Platform 3 is our partner and a lot of Karka kind of give details can take some of the other database technologies and move them into, you know, our Advanced Server into Postgres as well.

Greg Irwin 3:47

So Stacy, I'm, I'm an engineer by training, I like numbers, give us some of your glory stats. So how many enterprises are using? Excuse me, production grade Postgres, for production systems? What's one of the largest environments you've got? Give us, give us give us a number here that we might we might be able to jot down in terms of 30 here post production.

Stacy Scoggins 4:11

Yeah, so I in my role as North American Field CTO, right, I cover the commercial side. So some of our largest customers right in can't necessarily share names, non disclosure, but if you think about some of the largest credit card companies or insurance companies, they are utilizing our technology for their critical systems, right, whether it be on the cloud or on premise, or moving to the cloud. So definitely leave it at that and we can go into more details being references

Greg Irwin 4:41

I know you have big references, but we have some big enterprises on the line here. I know Nikes here Sherwin Williams here is current Cargill is here so some people are managing some pretty hairy environments. So if you

Stacy Scoggins 4:54

like like for you have top of mind that I know you know are open to disclosure are American Express right credit card processing, if you think about the number of credit card transactions that happened just this time of year or just happened last Friday, right, and that sheer volume of transactions, Marriott, right, we all know them as a hospitality provider. So we're working with those guys to really modernize their state and move that off of some Oracle systems and others into Postgres. And then if you want to go to the public sector side, the US Army, right is one of our key accounts on that side that has decided that Postgres is their standard, and they're running some of their what they call mission critical applications on Postgres Kerrigan stuff

Greg Irwin 5:38

all right, Stacy Awesome. Let's go on over to Karka. Karka can do us a favor, give give a quick intro yourself and Platform 3.

Karkavel Jegadeesan 5:48

Hey, guys, I'm Karka. I'm the CTO of Platform 3 Solutions. We are an organization founded in 2012. We currently have offices across America, Asia, in India, Singapore, Saudi and Australia. So we focus on application modernization by in more detail on legacy data migration, archival, and also on creating value by reducing the cost of operations, providing immediate ROI and providing application modernization benefits to our clients. We typically service fortune 500 clients, some Cargill is our clients. So I'm glad that you guys are here, they are already using our product, they use it for their modernization stack to archive data. So our focus is purely on application modernization, particularly on migration of data to Postgres, and also on archival of information to our own our own repository, our current data store. So we are a great partner with EDB. We support a lot of EDBs efforts, we have a connector to help facilitate and migrate DB two and Sybase and SQL data from these legacy platforms to Postgres, we feel we have, we are creating a lot of value in combination with what EDB offers, because that's enterprise standard, you just cannot. Like you cannot just take Postgres to an enterprise, it never works. They need support, they need enterprise standard, they need the credibility that comes with it. And by partnering with EDB, and with our experience on legacy technologies before when absolute brilliant value add to any, any clan, that's there

Greg Irwin 7:33

are Karka, let's stay on this event, folks, that's about the limits of any kind of sales pitch, I won't hide the lead, you want to learn more, obviously, you know, Platform 3 and EDB are doing this for awareness. So, you know, we'd be thrilled to connect people. But Karka, let's talk about some specifics about where Postgres falls down. And what EDB has basically provided that helps really manage Postgres at scale, either for management or performance. So what kind of things do you get with the, you know, when hardened Postgres? And I'm gonna pause, think about your answer. And while we're doing this, I need everybody to participate here. Go into the chat right now and share one question, as asked one question, either for EDB, or Platform 3, or any of your peers that are on the line here. Preferably, we're talking about Postgres, but it could be cloud databases, it could be migration challenges, it could be cost, it could be available resources, you know, anything that is a pain in the butt right? Now, let's talk about it, because those are the things that really matter. So do me a favor, take take a moment, as sophisticated a question or a simpler question as you want to put it in there, and it'll help us make sure that we're hitting things that you actually care about. Okay, Karka, I, I posed a question to you, what is what is really been hardened by EDP? The

Karkavel Jegadeesan 9:03

to start with Postgres itself is a great open source database. It offers everything, it's, it's great. It's very user friendly, it's, it's something that supports what I would call an end to end to an enterprise. So the question was, What does EDB Addison value what what where does EDB come in? Right? EDB adds an enterprise class on top of it, it's not about just using an open source database. There are things like high availability, things that an enterprise needs from an infrastructure standpoint, from an from a support standpoint, from a security threat. If there is a vulnerability, how does how does that get supported? How does that get fixed? That's not the job of a DB admin manager of an infrastructure administrator, you need a product organization to take responsibility to manage a product and create value by adding what I call an enterprise class right. Typically, what is not needed for Let's say a freelance developer, what an enterprise needs is security, it needs stability it needs. It needs roadmap, a vision on how the product is going to move forward. It needs. It needs other things like high availability and so many other things. So that's where EDB adds value.

Greg Irwin 10:18

Stacy, what do you think in terms of some of the issues that Cosby has been finding? And maybe their their ways some clients tend typically tackle? Yeah,

Stacy Scoggins 10:27

it depends on you know, what version you were using, right? You mentioned PG admin, but really version of Postgres ratings, because every year, I think the Postgres community does a good job of adding performance enhancements into every release. So we see incremental performance increases with with every release, 15 was released just a little less than a month ago. And our benchmarking showed, you know, incremental performance increases on that from, from data retrieval transactions per second. And a number of other metrics that my performance engineering team tracks. But as far as connectivity, right, and we can kind of take this offline, maybe it makes sense for you to use a pooling mechanism, right for that connectivity, like PG bouncer or PG pool to facilitate those connections. Because one of the things Postgres does struggle with right is the huge number of connections, right? And if you effectively manage that, and that's what we saw at Marriott, right, they have all these properties across the globe, and they're all trying to connect simultaneously, and leave connections open. And those two mechanisms, PG pool PG bouncer, allow you to pull those connections in, you know, kind of reduce some of that load on the database itself. If you want to reach out to er Karka or both, right, we can kind of get the appropriate documentation on that. And we're actually so one of my peers, right. I'm a general field CTO. So I cover all accounts, we have a gentleman that came from the banking and financial services industry, Julian, who's one of my peers, also field CTO, but he specializes in financial services. And I want to say he's been talking to some members of your team at Scotiabank, as well. Obviously, there's some open source opportunities for Postgres with. For high availability, we actually recommend when you start looking at high availability, and depending on your requirements, even extreme of high availability with five nines, we have what we call Postgres distributed, it was previously known as bi directional replication that came over second quadrant. But that can give you the five nines of availability, if that's required that extreme high availability. In fact, I spoke at the last Postgres conference in New York, as well as in Berlin, on this very topic, and we even in certain cases, right, so for all you guys that are that are out there for that, or Oracle base, we can even position it as an alternative, not a complete replacement, but as an alternative to Oracle RAC in certain scenarios, right. So we've done that for customers as well. And again, depending on the use case, we don't want to over promise and under deliver, but there are certain situations where, you know, this can be a replacement for all Baroque. So, Bruce Mommsen, who's one of my peers on the CTO team is kind of known as the godfather of Postgres, right? He's the guy that in 1986, resurrected the Postgres project, community project and kind of get that going, again, right from from a kind of restart re jump perspective, he always says that people come Postgres because of the cost savings, but they ultimately stay because of the all the benefits and performance and stability of the database. Right. So I think, from your perspective, right, you're, if you're looking at from a cost perspective, our Oracle is consistent with the based on your license agreement is consistent with the cost of Postgres. But what we bring to the table is kind of that that open source, right? The other thing, and one of my personal soapbox is, is the concept of portability, right? So we always, we as EDB, always push that the database you run on premise, should be the same database that you're running virtual machines should be the same database that you run in the cloud, right? Or in the physical, okay, physical data center. So that portability aspect allows you to if you're starting to think about moving to the cloud, but you're hesitant to do this application modernization or digital transformation, we encourage you to do so right, do it with Postgres, and then you can take that same database, depending on your chosen cloud provider and move it to the cloud. So that's one of the benefits is that overall portability. The database you run today, regardless of the deployment mechanism, can be the database you run tomorrow. With Oracle you're challenged right when you start to move to the cloud on your options. so that if that's a consideration, the other thing is, and one of our biggest customers, another credit card provider came to us and said, Hey, we really want to partner more heavily with you guys. Because we're struggling to get resources. And I'm sure that's something that you guys are seeing in this marketplace as well. We're struggling to get talented resources that no these older legacy databases are, they don't want to know. Um, right, they want to stay more on the cutting edge, right with open source. And so that was encouraging for us to hear that they, they really wanted to move to Postgres, because it's cool, right? It allows them to attract, you know, a new level or a the new talent that's out there coming out of college or, or, you know, fresh off of, you know, their first career move, and now they're looking to potentially consider, you know, this, this credit card provider. But when you start looking at features and functions, right, we provide very similar capabilities that are Oracle does, in our Advanced Server add Advanced Server II pass. So we provide monitoring, right? Postgres Enterprise Manager, right is comparable to Oracle Enterprise Manager, PG admin is the open source version of that, right. And Postgres Advanced Server is our flavor that that offers the Oracle compatibility. And with that, that subscription, we include Enterprise Manager that gives you additional functionality above and beyond PG admin. The tools that are very specific to the compatibility cover, come with our EDB Advanced Server. If you're looking at Community Postgres, then PG admin would be your chosen weapon for monitoring. The funny thing is, PG admin is completely developed by EDB, and provided back to the community. So that's one of our investments back into the community. Because we're good community stewards, right? We leverage the open source database, we want to contribute back. So PG admin is one of the tools that we provide back to the community as an organization.

Greg Irwin 17:17

Stacy, you're talking about portability? Are your clients at enterprise scale hosting EDB, in the major cloud platforms, on AWS, Azure and Google?

Stacy Scoggins 17:26

Yeah, so we can on all the cloud platforms, we can deploy in virtual machines, right? Or bare metal instances, if a customer wants a fully managed solution, then we offer what we call big animal, which is our Postgres EDB, is fully supported, fully managed Postgres in the cloud, right. And that's currently available on AWS. And as your write in Google Cloud Platform is coming on the roadmap in first quarter of next year, I believe, is the target

Greg Irwin 17:58

date. Huh, Donna? Got it? And is there better performance on any one cloud and others? Have you optimized for any specific platform?

Stacy Scoggins 18:08

We haven't really, with any database technology, it comes down to tuning and the workload, right. So we have tuning guys that we've published as an organization that kind of gives customers a baseline to get started. So we did some work back last year, early last year, before we had our big animal product, because we really wanted to see how we stacked up against, you know, the major cloud providers version of Postgres that they provided. And when you take out of the box of both right, we perform better. But then as you started tuning and tweaking, we were seeing much better performance magnitudes of you know, 20 to 25%, better performance than the options that came from the other cloud providers. Obviously, we tune theirs as well. Many times the variables that they allow you to tune on the database are scaled back versus you know, what you're capable of doing if you fully have a deploy database that you can tweak all the knobs and dials right. So I think that that kind of plays into your typical DBA tuning, if you do the database for the workload that is going to perform better than if you do it out of the box. One of the cool things that's being introduced in our big animal product is a kind of a science project or research project that one of my peers did around auto tuning. So we were challenged by our executive team on what can we do machine learning wise, right to help Postgres so one of my peers took that as a challenge. And he applied machine learning algorithms to Postgres and allows for auto tuning capabilities similar to the autonomous database capabilities that Oracle provides. So that's going to be introduced in our big animal product sometime early next year and then, you know, it may get scaled into an on premise deployment. But that's one of the ways that the cloud offering really differentiates itself is, you know, some of this fully managed and fully automated tuning capabilities.

Greg Irwin 20:14

Excellent Stacy and Karka. I know one of the key topics we weren't thinking about here was migrations from Oracle. So let's go through a use case, one story. And then I'd also continue to pull the group specific topics, I'd like to try and keep it, you know, not not get into the technical weeds. But any key topics you're interested in, maybe it's migration path from db to maybe it's, I saw her how long was it running in a Microsoft environment? We're gonna hit both of those. Let's hit the one in terms of some real stories here around Oracle migration. Talk to us about one Oracle migration, you don't have to share the company name. And basically, what were the greatest challenges? What made me I want to like talk about how it really went, you know, not how it could go, but how it really went?

Karkavel Jegadeesan 21:06

Yeah, I would rather talk about a BB to migration, because it's more interesting and more challenging. So, so there are a lot of perceptions about how people conceive the v2 and how people see Postgres, it's, it's what I would call polar opposites. Right. And with DeVito, there are typically a ton of challenges. And the biggest one of them is people's understanding of Postgres. And when you look at it from a dB, two mindset, you get these challenges, or you get this feeling that it's not going to happen, there are datasets that that are not compatible. How am I going to migrate this procedure that will not work with Postgres? What am I going to do with this? So what happens like and this is, I would get very particular with the client, right? What happened was that in their modernization journey, we started them with dB to post a migration. And then halfway through, they realize that, it's still not going to solve that problem of migrating into Cloud eventually, because the application stack still is so legacy that that also had to be migrated with the DB stack. And that means that restructuring the entire application, moving it to moving into a cloud based environment, and and how it connects and how it works, and how it's scalable. All of this becomes huge question marks, particularly because the veto is very solid, right? It gives you the comfort of solidity, it's very scalable. But it's also it also constraints you being on prem, it's, it's huge in cost. So, to outweigh this, what we proposed to the client was, you know, don't don't jump into the migration right now. Start by analyzing the application, spend the time spend that extra effort, knowing what your services are, how your DB is getting used, know, your stored procedures, the usage of the procedure, how many? What are the number of users, concurrent users accessing it, know everything about the database before you start your migration journey. And by doing that, see, I would say 80% 90% of your problem is solved. If you spend enough time and analysis, if you can, spend that time understand what you're getting into and then do your work. It makes it very, very simple. And this was a particularly hairy system, both from a business standpoint, as well as from a technology standpoint, it's the DeVito system has been around for about 30 years, which means that it keeps stacking up there are people who keep adding DBS procedures, which nobody knows is being used or not. And then the application gets transformed multiple times. And that adds into so much layers of complexity. But once you are able to spend that time on analyzing, fragmenting everything, migrating the application through its own strategy, migrating the middleware, migrating the DB, and figuring out how everything sits and works with each other, testing it properly, it makes a great and very successful migration.

Greg Irwin 24:08

And how long did it take? Me? Okay, so given given the high level of environment, size was complexity, you know, then how long? How long did it

Karkavel Jegadeesan 24:19

take? So if I say, hey, I can get get this done in two weeks, that's not true. Because you know, DB two systems are pretty complex. So two years, could you get that particular one was about four months. But I would never use that as a benchmark, primarily because it can be like three times more time consuming or two times less content consuming. Depending on how many technical SMEs you have, depending on the first thing I would say is the in house experience on your legacy system. That's the first most important criteria then your readiness as in how many years is your target infrastructure? How ready is your organ A session to facilitate that migration with access with so many other things. How good is your testing team? So there are many factors that will define the timeline of what it takes to migrate. It's never the same, I have not seen two organizations have the same kind of experience it it, a lot of that depends on readiness expertise, and who you employ to provide you with the services to do the migration. So it all boils down to that.

Stacy Scoggins 25:26

Yeah, and I would, I would echo what, you know, Karka says, is really dependent on the customer's environment, the time to migrate the database, right? So define that, are you talking about just migrating the schema, because that's part of it, but then migrating the data? Right? That depends on how big the data is, how many databases are and things of that nature. But more importantly, right and Karka loop is just the prep, right? Getting ready ahead of time to make sure you have all of your SMEs in many times as we're seeing in organizations SMEs have gone right, so these legacy databases and applications are running on autopilot, and everybody's afraid to touch them. Because nobody knows what they do. Right? So that is a scary situation when you don't have the SMEs. And now you need to test with a new application. Right? So understanding what you have is critical, the migration piece, right? The semantics, and the process is very well defined both on the platform three side and our side. But then more importantly, at the end, is that whole testing, right, and getting the applications involved early on, and not just thinking here to flip the switch, and all of a sudden, you're moving from your legacy database to the new database, and everything's gonna work fine, right? Because in a fairy tale war, that's that's the way it works. And

Greg Irwin 26:41

I think took me a little bit, but now I've got a good question for both of you. Do you need to answer with a number? Just answered with a number? I'm gonna preface that before I asked that question. I you have 10 Big migrations enterprise class migrations, 10 of them, some from db to some from Oracle, some from I don't know, pick Sybase pick your favorite database. How many of them after the end of one year are considered a success in their migration to Postgres SQL, and I'm sorry, these include cloud migration, because I think a lot of the folks here are doing this as part of a cloud transformation from on prem to cloud. So let's say that there's our there's our game. Stacy, how many of them are successful out of 10? out of 10?

Stacy Scoggins 27:29

So yeah, define successful or completed,

Greg Irwin 27:31

or CEOs, your CIO is going to tell his his board whether it was successful or not. Now,

Stacy Scoggins 27:38

yeah, I would say probably 75 to 80%. And the ones that fall out really fall down in the categories that Karka and I alluded to earlier, right? It's either testing or, you know, just not being prepared. So it's not a surprise. The other challenge given I think,

Greg Irwin 27:55

we're gonna get into it, but I want Karka number. Before we get into cars. You got to tout big enterprise migrations to her to Postgres SQL and the cloud, how many of them are successful?

Karkavel Jegadeesan 28:07

80 to 85%? I would say, it's because of the experience, I think we have read about mutations, but that's usually the number that I see. And the reasons of the failure, I would take one minute to talk about that, right? It's, it's, so let's say there are 100 failures, right? Only one among those 100 would be of a technical nature, it's mostly about process readiness, teams available for for validation. And the SME knowledge and validation is extremely important. So what happens is, during the migration of data, and the procedures and all those things, an extraordinary amount of time has to be spent for validation, setting up validation protocols, having hash based algorithms to do compare of the source and target databases, which is the data validation, and then validating your store procedures for functionality by business for technology outputs being the same by your application interfaces, doing this multi level validation makes a product very successful. So of the failures, the 15 person that I would call failures. Maybe one person could be for a technical reason. Otherwise, it's mostly process oriented.

Greg Irwin 29:17

How many of them have a financial payoff, meaning you're actually able to drop your DB two licenses or your Oracle licenses in a way so that maybe maybe you have to spend to cross the chasm. But once you cross that chasm, you're at a much better run rate and running more efficiently and you have the portability. You talked about Stacy? And you have the HA and all the features that you talked about Karka what percent out of 10 are financially financially successful? Yeah, I would say

Stacy Scoggins 29:50

that number is much higher right. So no one has 100% Because nothing is is always 100% But But close right? Because we can typically at least on the Oracle side, so saves customers, you know, 60 to 80% of their Oracle costs, their license costs. The challenge many customers have those are state is so large, right? And their license contract is, is so complicated with Oracle is how do you unwind all that right in, in save incrementally, as you start to move these databases over, because nobody's gonna move, you know, hundreds of databases at once. And they're going to start doing a methodical manner. So we have to work with companies to figure out, you know, what's the best way to move it? What's the biggest bang for the buck? And then how do you kind of unwind that Oracle commitment that you have? Every renewal, right,

Greg Irwin 30:38

we had one of them, I said, that's part of my 10. If you can't unwind it, then it's not successful. Because Oracle, these guys are smart, they are ready to just let the licenses go, oh, you can drop those two, but please pay us for the other eight. Now, they might they might say, sorry, it's the same cost as 10. Right. And

Stacy Scoggins 30:58

one of the one of the challenges, right, that we have typically is customers come to us to say, Hey, I renewals in, you know, they come to us in December, January, say I renewals up in June, right? Can you help us move these databases, and we have to be realistic and say, based on what you're trying to do six months is not enough time, right to do that, and help them understand what that is. And then they can make an educated choice on do I extend to extend part of the contract right in how they move forward. So giving yourself plenty of runway, right, as you're considering a migration from any database platform is obviously the prudent thing to do. And many times we see customers want to do, let's take our biggest nastiest database, and move that one first. Because we think we're gonna get the biggest bang for the buck. My challenge to them is, yes, but that also sets you up for your biggest chance of failure, let's take some smaller legacy databases, move those over, right, they're going to be simpler, we're going to learn from it, we both write from your side, in either side, you're gonna learn the process or people we're going to get more educated on Postgres and how it works in your environment. And then we can get that confidence and build into those bigger databases. You know, in later phases.

Greg Irwin 32:11

The question from Manish on validation, let's hit this one and just knock, make sure we covered, you talked about the importance of validation. The question is, do you have tools built? And how do you actually execute the validation of databases that are migrating? Yeah. So

Stacy Scoggins 32:29

you know, I'll let Karka kind of jump in on their methodology, we do have a tool called Life compare, that allows you to compare the databases, you know, results between the two. So that's one way but there's nothing better than then the application testing, right and running the results on both sides. And seeing that you're getting the same results, same response time, right, and all the metrics. So thorough testing, in my opinion, can't be replaced by tools, they can help augment that process, and maybe accelerate the process. But it's still that manual. Tic for tack within the databases, at least at some level, to ensure you're getting consistency across those is still very important. Yeah, I'll look Karka, adjusted DBQ on the on the Oracle side, right, our migration tooling. Typically, we move table for table, right. So in a migration scenario, you probably don't want to do a lot of combining of tables, right, you want to move it like for like, so you have an ease of comparison. Now, obviously, with some of the application modernization, then that changes some of the rules. But typically, that's kind of the rule of thumb that we follow. So when we start looking at, you know, what, you can actually go out now to our website and go to the migration portal, and you can upload your schema, and it will tell you how compatible it is your Oracle schema is with our Advanced Server, right? So the ones that are 100% compatible, we fully know that those are going to move over, right, we have those kind of 10 years worth of history to be to have confidence that those store procedures, functions and things like that are going to move over the ones that that are noted as exceptions. We also have enough flight time with them that we can probably apply programmatic ways of moving those over, but those are the ones that we tend to test more heavily than the ones that are unknown, you know, good as they move over cleanly from Oracle to

Karkavel Jegadeesan 34:30

Postgres. Alright, from DB two perspective, right. I saw two questions come up. One is how the data validation happens. And the other one is how do you facilitate and automate the migration itself? Is that correct, Manish Okay, so to automate the migration, we have a tool called analyzer that analyzes all the stored procedures, objects, view schemas, everything in the v2 and it facilitates them migration of DB due to Postgres, I would never say 100%. But 90% of this migration gets automated at this pace. That's point number one, and validation when it comes to validation, right. So, the data validation cannot happen if you are doing transformation during validation, okay. Now, that being said, DB two has some native challenges while you are migrating, for example, right? timestamp is a is a data type in dB two that is not supported in a process, you will have to call it a varchar. Right. But then what we do is we write functions to on top of the on top of the field that makes it behave like a timestamp so that from an application layer, it never creates a problem, right? So you have to do these minor changes. But from your validation standpoint, from a data validation standpoint, what we do is we do a hash based comparison. So it doesn't matter how, where the data is, whether it's supposed to be a or b, we do. It compares apples to apples, it compares every table, every field, every table, every field on it at the data level. And it provides very clean insight on if the if there are if they're identical copies. So that's a very, very complete way of validation. And then we also provide test case based validation. And all of this is automated. And I can get into a lot more details. But we can probably do that as

Greg Irwin 36:31

well covers that maybe what I suggest is, if you want to see some real examples or hear some more detailed use cases we do we do do it through some follow up

Stacy Scoggins 36:40

Yeah, that's why we partner with with Platform 3 right around the DB two side because our Oracle capabilities are very similar to what Karka describe, for the DB two side where we run it through the migration portal, you get transformation, not transformation, but you get the the transformed schema. And then we manage the exceptions, right and give you one real quick example, right, we had a customer that had 10,000 objects in their database, right that they were checking compatibility. When they ran it through the migration portal. We were 91% compatible, right. So we had 9% fall out. And those really kind of were around to Oracle packages that we didn't have built into the process. But we had seen those before, we had a programmatic way of handling those, when they did their estimate to go to community Postgres versus Advanced Server that has that Oracle compatibility, they were really only 35% compatible. So they estimated that it was going to take them roughly a year to a year and a half man years, right, you can, you can put many people in a room and get it done quicker. But the level of effort was roughly a year to year and a half. When we took ours, right, the level of effort was 35 days, right to move the schema of the data. Now, again, testing and all the infrastructure that the Karka alluded to earlier, extends that timeframe. But you can see the huge view just savings on manpower of using programmatic ways of migrating versus doing it manually yourself.

Greg Irwin 38:11

Let's keep going. Mattis thanks for the question. And validation is something that matters to everybody. So it's a good it's a really good topic. Look, I want to hit on a question that came in. To me directly. It's I think online with again, what I think a lot of people are thinking about, which is, given the cloud migrations coming our way? Do we really have to reinvent the wheel for Postgres SQL? Because it's available as a past solution on clouds? And what are the major advantages of going with Community Edition? So there's two, two separate threads there, but I'll hit that. I'm going to ask Stacy, if you would hit the first one, how much reinvention is needed? And in what situations is reinvention needed to basically go to Postgres SQL on path?

Stacy Scoggins 39:02

Yeah. So when you look to go into the cloud, right, and that's less take database specific out of it, right? Just a, Hey, I'm looking at an on premise solution versus going to the cloud. You know, my earlier comment about portability, I think is key right? Of being able, because even portability between cloud providers is important. So if you're going to a platform as a service deployment of Postgres, then you're pretty safe on premise moving to the cloud, right? It's a different deployment pattern, right? A different location, but the data base is going to function the same. Now, if you start going to cloud providers, very specific versions, right, AWS or Aurora, or rds, right? Microsoft SQL Server, Postgres Server on Azure, then that kind of changes the rules, right? Because now you're in their sandbox, and they put limitations around what you can I can't do to be able to support that as a database as a service, right. So Platform as a Service services Database as a Service is an important distinction. For us, the way we view it at EDB. is it's a deployment mechanism, right? So Postgres is your database, right? Pick your flavor, whether it's community or are ours with Oracle compatibility, or the hybrid in between that standard edition that includes a lot of our tools that we add on. But really, Postgres is your chosen database, where you choose to deploy it in containers on the cloud, or on premise is really a deployment mechanism, and not really a consideration for your development application teams. So hopefully, that answers your questions, we can dive into more details if we need

Greg Irwin 40:46

Maybe. Maybe I go to my one out of 10. Again, look back to your look back over the course of this year, on your projects, where you're migrating to a cloud environment, how often are you having to do some refactoring on on the application stack or the database architecture? To, you know, to make this perform? Yeah, that's,

Stacy Scoggins 41:12

you know, it's hard to answer because usually most of the time, you know, throughout all the buzzwords, right. But as customers look to move legacy databases to the cloud, they're doing digital transformation, application modernization, right. So by nature, they're changing functionality within the database, right and within the application to be more modern. So those dictate natural changes to the underlying infrastructure itself. But I don't know if we've had many direct, you know, kind of thing, the off the top, my head, any that are on premise Postgres that went to the cloud that weren't successful, right, because you're already on Postgres, and you go to Postgres on the cloud, either, as you know, a VM or bare metal, or, you know, in our big animal, then that's pretty straightforward move. It's really the whole refactoring of legacy databases and application modernization, that's dictating changes to the underlying database, those kind of come part and parcel together, right with a lot of our customers as they look to move to the cloud. And we're seeing a lot of customers doing the same thing right there, their goal is to exit off of their legacy database platform, right, you choose your flavor. And the first way they do that is say, all right, no net new investment, right? Any new investment is going to be on my chosen database of choice, we would like for that to be Postgres in many times that's in the cloud, right? So they start with greenfield development in move those databases to the cloud, with the intent of getting that experience right in the cloud with that database provider. And ultimately, you know, at some point, I'm migrating off of the legacy databases into the cloud as well. But I think that's a good good step to move forward with is, you know, any net new development, right? Do it on your chosen future platform, and then bring the legacy databases along, as it makes sense, right? When you have to do major maintenance of those, modernization of those, or your license agreement is expiring and you want to save costs. You know, it's challenging to be to be honest, but like in the situation you're in, and you really got to gotta figure out what what's important to your company, right? Is it open source first, which is some of our customers major initiatives? Or is it truly cost savings, right, and in figuring out that business value assessment for moving to Postgres, knowing that you're going to lose some of the economies of scale with with your vendor that you have currently. But I have one example of one of the major customers that I worked with, over the years, they let the database application teams kind of run amok, right, they let the animals run the farm. And so they had 32 different database vendors that they were dealing with, right across their enterprise. And they said, you know, this is crazy, we can't negotiate deals, right? Based on scale, and utilization with this many database vendors. So we're gonna standardize on three or four, right? And we want you guys EDB to help us understand how Postgres can do that. So fortunately, we were one of the ones that were down selected, and they are currently moving a lot of their state over to Postgres, but that was an organizational decision, right? They realized they had database for all and it was difficult to maintain difficult there their challenge was how do I get resources? How do I get DBAs that can that can support all these databases, right, then some, some obscure ones, some some more common places that could get Oracle DBAs or whatever, but how can we repurpose those skills of our internal resources to utilize right, the Oracle skill set on Postgres right or Microsoft skill seven Postgres. So that's, that's some of the challenges. The other challenge they had is they didn't have an internal chargeback model, right? So why would I, as an application owner want to switch to from Oracle or Microsoft to Postgres, because one is only going to cause me pain, right, I'm gonna have to go through the migration process. And me personally, I'm not going to see my team is not going to see any cost benefit, because their chargeback model just charge a flat costs for databases, right. So we work with them to change that that chargeback model so that the underlying teams realize that using Oracle or using whatever flavor of database actually costs them incrementally more from a license perspective than it did to go with, you know, in EDB, supported Postgres. And that really opened up the eyes of the developers in the application owners to say, hey, look, you know, I'm held to a p&l. Everybody's got budgets, right. So this is more cost effective for me. And, you know, that that really drove some of the decisions as well. But I think you got to take it from a multi prong approach, right Malik and, you know, either us or platform three can can definitely help you guys with that business case.

Greg Irwin 42:40

It has to help to have Postgres EDB in there as a just to keep Microsoft and Oracle honest, they are just a hedge just to hedge on skills. And you may not move everything. But it does. It does help to say I'm running the same same scale workloads, the same performance at at half the costs. And I can move more if I needed to. And like every company that's on the line here is running a dozen databases. Whether whether you want to be all Microsoft or not, there's no doubt. Anyway, we're at the hour, it was a good conversation. I know we bounced around a little bit, but I think we covered some key points A big thanks to Karka and Stacy for CO hosting here, folks. We're gonna send out you know, a thank you. And I want to encourage you not to not again not to bury the lead. Follow up here with these guys. Yeah, even if it's just for a little bit more information or just to to make sure you're covering your use case. This is very general, but obviously, you know, these guys and their teams can go as deep as y'all need to at least lay out some options for you. With that, let's let's get back to our day jobs. Karka. Thank you very much. And Stacy. Thank you very much.

Stacy Scoggins 47:22

Yeah, and thanks everybody for your participation right it's good.

Greg Irwin 47:27

All right, everyone have a great day.