 Specifically today we want to talk about moving data from your legacy Oracle systems to your OSRIS real-time systems. And this is our agenda for today. We'll do like very quick introductions. Talk a little bit about why real-time data ingestion is a bit more difficult than, you know, you might expect. Then of course we'll introduce the Equalum platform solving those challenges. Talk a little bit about our Equalum Connect platform and share some customer use cases. I know this sounds like a long deck, but I promise you guys this is going to be a very quick deck and we will focus on the last part, which is our demo, live demo. And of course leave some time for Q&A at the end. All right. So let's start off by introducing myself. So I'm Arizo Sheikh, the VPR product for Equalum. I'm a data guy. I've been a data guy for quite some time now. I did a lot of time. I mean, well, actually that JD will love that. I did some time sounds like jail time when talking about Oracle that might resonate, right, JD? That's absolutely right. Yeah, I did some time doing Oracle DBA about 20 years of that. I did also some MySQL and SQL Server, mostly Oracle. During that time, I've done a lot of data replication, data migration and ETL projects with various tools, various needs, various use cases. And the only common thing is that I've always found them extremely complicated, cumbersome and tedious. So I know how challenging those projects can be. And that's pretty much why I joined Equalum around three and a half years ago as the VP product to kind of help others do exactly that. And I was happy to find a group of data enthusiasts, which are a lot of us are DBAs, data scientists, architects and developers, all with a lot of data background, you know, kind of understanding the pain points of data and data ingestion in particular. And we've all kind of, we are all committed to two things, basically liberating data, meaning that you do not need to, you know, be a kind of a slave of the operational platform that stores your data at the moment if you want to use that data for other purposes. I know moving data out of a database or out of the system is super complicated, but it can be made much, much easier. So that's why we call it liberating the data. And in general, making real time data ingestion at scale, easy. That's what Equalum is all about. And with that, let's talk, you know, a couple of seconds on why real time data ingestion is so hard. So the first part of real time data ingestion is basically getting the data out of your systems, or your most most commonly the operational databases or operational systems, which hold your actual live production data and extracting changes from those data sources is very, very complicated because a lot of times it's done in a very intrusive way, just going in querying data every hour or every minute or every night. Those are very, very intrusive operations which usually will not be permitted during daytime or doing peak hours. So doing that in massive scale, if you have a lot of data, a lot of changes in the data, getting that data out of the systems is not an easy task, let alone if you want to do it in real time because you want to consume the data in real time. The first part, basically the first enabler for real time data ingestion is getting the data out of your systems. And we'll talk a lot about how Equalum does that in a very effective, non intrusive way. The next step is, all right, so you got your data out of the system. How do you now transform the data to a structure and a format that is usable straight away on the other side. I like to interject here. From my experience, that's actually one of the more challenging parts, right, because when we're talking about something like a legacy oracle database who doesn't do proper data typing, or doesn't have certain types like Boolean, and then you're ingesting it into Postgres. You have to, if you're doing CDC, we have to be able to transform that on the fly. Is that your experience? Exactly. Yeah, so this is one type of transformation which is associated with database migration. You want to migrate off of a platform into another one. And you have all these challenges, just like you mentioned, you know, data type conversion, some logic that is done a bit differently on different database platforms. Yeah, that is exactly, you know, one of the pain points that people experience. And there's also more, let's say, business logic that you want to implement. So, for example, let's say that you have changes occurring on your oracle database and you want to move them to your Postgres data warehouse, right. And you want the data to be aggregated in order for the report system to use that, right. So usually traditionally, you would, you know, load the data into a staging area and then perform the aggregations every day or every hour. So if you want to consume the data in real time, you need the data aggregated on the spot. So aggregated, cleaned or cleansed, joined, you may want to join a few data sets, you may want to, you know, filter out bad data or fix the data to be good and correct. All this should be done, if you want to consume the data in real time, it should be done in real time between the time you extracted the data until you loaded it to your target. So that is another layer of complexity in these kind of projects. So extracting the data, transforming it to a format and a structure that can be used in real time. And then doing that for hundreds or thousands or tens of thousands of tables, right, or ingestion processes, while automating it, managing it and monitoring it, now that becomes a nightmare, right. And still do everything I mentioned with scripts or, you know, your own procedures, if it's, you know, like five tables that you know very well, but doing all that in scale really becomes a nightmare, especially if you're doing it with like scripts and command lines and stuff like that. Well, wouldn't that be one of the value adds of a package product? Sure. Because I mean, open source folks, I mean, I'm an open source guy, right, and I love the not invented here and being able to code my own, you know, I want it to work just this way. But as I've grown as a professional, I realized I've got better things to do. So the return one of the return on investments here is that you take that nitty gritty op level automation and monitoring away from yourself and you put it into this platform and that way I can focus on actual interesting tasks. Exactly. I couldn't agree more. I mean, we all love we I assume that we're all, you know, hands on people. I can still say that about myself. And I love and you'll see that in a second in the demo you'll see the nice equal of you either you also see, you know, command lines, which are going to use and I still love doing that. But as you say, I used to love that much more when I had, you know, much less to do, you know, the earlier days of my career but then when you're managing much more databases much more data and you have, you know, the business requires you to do a lot more than just you know, managing the database, right, then all of a sudden you find anything that can kind of help you be productive you find it very useful right so you I base tools, which automate things and manage and monitor things for you so you don't need to kind of refresh on a on a system to check the status is something that I think is invaluable when you have much more complicated tasks to do. And I don't want to divert too much here but I'm interested in your point for before you get started on this, because you got to buzz words here, Enterprise grade and no coding required from experience I mean you're a tech to you know that you know no coding required, sometimes is not quite as up to snuff as people would like, and then Enterprise grade is really a marketing term. And there's nothing wrong with that but it's something that I think we need to define here, so that people don't feel like we're just, you know, throwing the buzzwords out there. And from what I've learned about your software, it truly is Enterprise grade and what that actually means, can you define that per your definition. Sure, sure, sure. So first of all, again, the deck is going to be pretty short, and everything that is written here will be demonstrated live. In Enterprise grade, what we what we mean usually or what our customers need is first of all skill ability, high availability. So you want to high availability is a must. So you want to be able to recover from any failure, you want to keep going right you want to be available. Scalability is another issue, right where data grows, you need more and more power you pretty much want to be able to process any amount of data in reasonable amount of time. Some aspects might include exactly once semantics and in general recovery from failures. So we equal guarantees data to arrive from source to target. Exactly once not twice and no, and not none at all, like not not at all. We actually guarantee data to arrive only once now this sounds very, you know, straightforward or very easy to do for, you know, database guys but I mean data I mean the databases guarantee that most of them, but moving data around the enterprise in a high scale, where anything can break, you know, in the middle the source the target, the software like the equal software network disk, whatever, still we guaranteeing that exactly once semantics is not an easy test. And I can go on like about monitoring and security, and all that, and we definitely have all these enterprise needs in place and ready for an enterprise user. And I'll show some of those as we go. The no coding required part is is also extremely important it's actually part a big part of our offering. So if you have to start coding, you know, within the platform for doing any, you know, each one of your data ingestion pipelines, then I feel we haven't, you know, given any value at all, because you can do all that yourself. So Equalum does offer some coding capabilities for the people who insist on coding their own code. And we refer to those as user defined, you know, functions or users defined operators or a bunch of other like pluggable capabilities. And it's intended to use in a non coding way so everything is done in a super simple UI, which you'll see in a second, which really drives productivity up our customers, basically a test that Equalum UI is more productive like three times more productive than other, other tools that have you concept and much more than that for doing stuff yourself than doing stuff yourself and you know scripts and code. So, so these, this is the kind of an overview of the Equalum platform and as you can expect. We actually aim to solve all the challenges that I just talked about so the platform is kind of in the middle between your sources on the left to your targets on the right. So we're going to focus today on Oracle to Postgres but Equalum supports a lot of different data sources and targets. So basically you can get data off of your cloud services, different RDBMS, NoSQL databases applications like SAP Salesforce and so files on S3 or on HDFS or on your local file systems, and so on and so on, message queue, we have a lot of different data sources. And then on the other side we have a lot of different data targets, again, cloud services, database, data lakes and so on and so on. What we do, as you know in between those data sources and targets is first of all, of course we extract the data from the data sources just like I said, we do that in real time in a non intrusive way. I don't know how many of you are familiar with CDC. CDC stands for Change Data Capture, and that is a methodology of extracting changes in real time as they occur from different systems. Being a methodology, it's not a technology, it's a set of principles that basically say let's get the data non intrusively as changes occur on the source and the implementation of that methodology for each source is very different because each source works in different technologies and different ways. So the first part, yeah JD, you want to ask? Oh, I was going to ask, what is the most unique data source that you have? So that actually depends on your definition or your needs, but we can actually read low level events from files and databases, but we also have the ability to read business level, application level entities from applications like again SAP, Salesforce, Facebook and a bunch of more applications. And those are pretty unique because what you get is not the low level entity, you can get a business object, which is actually, you know, it might reside in like 20 tables in the database, but you get any change on the high level entity, like let's say an order, right in the e-commerce system might be a complex object with the order, the order lines, the products within inventory, maybe some promotions, and so on and so on, and maybe the user details like the customer. So this will be a complex, hierarchical object that we will treat as one CDC event. Every time it changes, we can get that event and treat it as one event with all the data within. So that is kind of unique. And, I mean, we have a lot of different data sources so each one of them can suit, you know, different needs. Great, thank you. Sure. So we got the data and again I will talk more about CDC and how we do CDC just in the next slide. Pretty much, but that is a big part of the offering because again, CDC is about getting the data changes of the data as they occur, non-intrusively off of the system which enables, you know, this to be done on a production system 24-7. You don't have batch processes running all night long for hours and then failing and getting into the, you know, day window just to be stopped and restarted next night. You don't have the lag of, you know, collecting data only once a day. You have fresh data coming in all the time without impacting the source system. And that is what CDC is about and Equalum has a very big robust library for CDC, which we'll talk about in a second. The next part is transforming that data. So like I said, we can do source to target replication, which I'll demonstrate very soon. So that means like every change from your Oracle system will go instantly into your Postgres system, whether it's on cloud, on-prem or whatever it is. But we have more complicated capabilities to do real-time transformations on the data still in real-time. So as a change is streamed into the system, you can transform that data, add new columns, remove columns, add calculated fields. You might want to do in-memory lookups to kind of join a few different data sets. So theoretically you can join your Oracle data with another Postgres operational data and another DB2 data all together to one event and push that event to your Postgres data warehouse. And you can do that in real-time. You can aggregate data in real-time. You can filter data in real-time and so on and so on. We have full-blown ETL capabilities, transformation capabilities. But the difference between that and most ETL tools that is it can be done in real-time on a per-event basis. As an event comes in, it will be transformed and pushed immediately to the target. When pushed to the target, we have various ways of doing that as well. You can either append data, meaning that it doesn't matter what operation happened on the source, whether it's an insert, update, or delete. We will log that data in your Postgres data warehouse or data lake. We will say, this is what happened, an insert, an update, or a delete. On the other side, we have a replication mode which says if it was an insert, we'll insert a data. If it's an update, we'll update the data. If it's a delete, we'll delete the data, keeping the source and target in sync. And the third option is emerge or absurd operation, which means if the data is there, we'll update it to the newer values. If it's not there, we'll insert the values. Overall, as you might get the sense so far, this is a multi-purpose tool for pretty much ingesting data from anywhere to anywhere, either for application or for complex real-time ETL. So data is ready for consumption on the other side a second or two later, sometimes less. Like we mentioned, the main points we want to talk about here is unlimited data scale. I mean, I need a data volume we can scale from a few rows per second to a few million rows per second of changes. We have a very low latency because of the change data capture approach combined with a real-time transformation approach. I think on the next slide, we discussed that a little bit about the low latency and how you achieve that with Postgres. Yeah, sure. So just to give you a quick idea of use cases you might be interested in. So first of all, extracting changes in real-time from your data sources. A lot of time that is the need by itself. You want to extract the changes and be able to react to those. And that can be leveraged for, like we said, replicating your awkward data to Postgres, any oracle to any Postgres, RDS to RDS, RDS to on-prem, whatever, any oracle to Postgres. You might want to replicate your operational Postgres system to your data warehouse based on Postgres. You might want to migrate your data from on-prem to the cloud. You might want to publish your changes from the Postgres database to a PubSub system like Kafka and so on and so on. And again, talking, mentioning again, you want to do that in real-time without writing a single line of code. So we have only like two, three more slides. So, I mean, the demo will be up in like five minutes or so. So our CDC connector, this is definitely not the full list. This is just a few that I thought might be interesting. We have a bunch of relational databases, but also files and applications. And what I wanted to mention here is basically just give you an idea of how we do CDC. So in order to do CDC, basically, if you're talking about relational databases, each one of those have a similar concept of each one of them has their own binary logs or write ahead logs or transaction logs or read logs or each platform calls them a bit differently. But those are usually the consistency layer of that database. And those are the logs actually log every action done on the database, not for CDC, not for us. It actually does it for recovery purposes. So whenever the database fails, you can roll back or roll forward the data to get to a consistent point in time. And that is like an internal mechanism each database stores for, again, backup for recovery for consistency. Okay, arrows. Yep. I've got a couple of questions here, which I think are appropriate. Both of them are kind of meat, what I would call a meat question. The first one is, is what is it that you're using? I mean, obviously it's logical decoding with Postgres QL, but how do we ensure a low latency of CDC from your source to your target? Because in certain transactions and certain, you know, work models, low latency is absolutely key. Yep. So the key here is, first of all, using, like you said, we are in for Postgres, we're using logical decoding, which I assume a lot of you are familiar with. So that is kind of a framework to analyze the data in the logs, right, in the right-hand logs, and get the changes decoded from the binary format that is stored in into a more readable format. Right. So Postgres by itself offers a pretty low latency logical decoder where you can, you know, get the changes that occurred on the database in pretty much real time. So that is the basis, right, for all this CDC and replication part. So we're moving forward to this, you know, kind of explanation. So this slide. So we use logical decoding to get the changes, right? So some of you might say, all right, so that is the, that's the heavy lifting, right? That's the tough part, getting the changes out of the database, right? We talked about how difficult that was. But that is only the beginning, right? After you do that, you're faced with a lot of other, you know, problems and issues. First of all, CDC data is great, but CDC data can only, is only changes that can be applied on the current contents of that table or database, right? So before starting to apply changes, you need to first obtain the full copy of all the data in the table. Before you start collecting changes, you need to do what we call an initial capture of all the historical data in those tables or in the database or schema. So that is one part doing, you know, because changes you can have, you know, like, I don't know, like 1% of the data changes daily, right? But you still need to load 100% of the data as a baseline. So that can, in some cases, these are, you know, a lot of terabytes of data that you have to move around just to start your replication process. So before we, before we move on with that, the second meat question, which comes back to enterprise grade, which I think is important because it actually applies directly to CDC, as well as what you're going to go into with like queuing tables to catch things up. Now we all know Postgres never crashes, but when legacy oracle crashes, how do you know what point you are at when it restarts? Yeah, that's a very good question. And we actually spent a lot of time covering all these different scenarios. So what we do is we have across the tool from, you know, our Equalum Connect platform that reads data from the source. And then it stores data in an intermediate storage within Equalum, and then data is picked up by our processing engine and finally written to the target. We have six steps here. And in each of those steps, we have checkpoint mechanisms that allow us to keep track on what we read, what we read and what we wrote for to the next step. So basically, we keep everything transactional. So while we read data, and rewrite data to the next step, we log everything we've done in a transactional way. If something fails in the middle, we know exactly where to pick up from. So this is exactly how we guarantee are exactly one's semantics, by keeping checkpoints of, you know, everything we read, everything we wrote in each part of the application so we can survive a source failure, an Equalum failure, a target failure, network failure, anything that fails, we will definitely continue from the exact same place where we stopped last time. Okay, great. Thank you. And that is actually a big part of the problem here, right, a lot of a lot of organizations who try to do stuff, these kind of stuff with either open source components or by themselves are faced with this exact problem and a lot of them sacrifice the exactly one's semantics because it's just too difficult, and they settle for at least one's semantics, which means that you can get the data twice at the target. And for some use cases, that's, that's fine. But in a lot of use cases, right, if you want to, if you actually rely on your data at the target, you want to get that data exactly once. So this is actually a very big problem in this in data ingestion and in real time data in particular. So yeah, yeah, thanks for asking some very important points. So other points that you might want to cover when doing replication or real time data ingestion is so you got or you managed to do the 100 terabyte data load into your target. But how do you synchronize the CDC data with the initial capture data right so you have you managed to load the entire data but now you need to only apply changes from the exact same point in time where you read the initial capture data from. So this is a big task also for each one of these databases and we've actually implemented again different techniques for each database to synchronize the initial capture data with the CDC data show again we guarantee two things. First of all, we'll first apply the initial capture data to your target, because if I try to delete a record that is not yet there, I'll get an error. So I need to first apply the initial capture data and only then the CDC data, but other than that, we also guarantee that we will not, you know, send data twice. Part of it as initial capture and part of CDC and will not lose data in the kind of in the point where initial capture and stops and CDC starts. So we guarantee exactly once we guarantee ordering of events and all that is not very easy to achieve. The next part alright so you got your CDC data you got your initial capture data but we're alright so you extracted them out of database. What's next right. So a lot of times, you want to do a multi table or a schema or even a full database replication to another target right so you want to have everything automated right you want. You want a tool to create your target tables for you, you want a tool to synchronize all DMLs or all changes but you also want to maybe react to changing schema at the source right schemas change very often. And if you add a column for example you want that change propagated all the way to the target so replication does not break. That is another PC have to you know enable on top of the CDC. Of course, if you're looking to do real time transformations. That is something, again, you have to put in place. You might want to write to multiple targets and multiple formats and not just, you know, one to one replications. Like you mentioned before JD, you want your source data types to be converted properly to your target data types. So if you try to, let's say Oracle stores things as a number whatever. And you know you want that data, as you know like a big end or whatever other more specific data type. You want the tool to be able to implicitly convert the data from the source to the target. Again, not necessarily an easy task. So these are just a few example examples of what replication and real time ingestion entails that is not part of the low level CDC. That's just the beginning of the process. And of course, like I said you want to do all that was a zero coding UI, you want to have built in monitoring and alerting, you want to have exactly one guarantee you want to have high availability in place, and a lot of others bunch of stuff that that you are an enterprise grade 24 seven tool. I'll try to do this more, you know, a salesy part very quickly. I'm not going to stop any slide but just we work with a lot of different companies worldwide, not all of them are big enterprises. This is just a standard, you know, slide from our deck but we work with a lot of different companies across industries. For a lot of different use cases, a lot of them are real time analytics or real time data we're seeing use cases. I have a few examples here. Again, we'll just go over them just in like couple words on each. So companies like Siemens doing supply chain optimization based on real time data. EOG resources and oil and gas company in Texas, they do actually an interesting use case of analyzing and monitoring their sensor data from the drilling wells to kind of alert on any safety issues and production level, you know, aspects. Warner Brothers do marketing campaign analysis, the ones of you are watching CW shows, for example, they advertise those on social media and they want to get you all to watch those on your on demand app or website. So we analyze how each post makes you guys go and watch the show. So a bunch of, you know, we talked about the technical use cases these are more a bunch of more business use cases for real time data ingestion. And with that, I want to switch to equal them. This is equal them. And basically, as you would expect, on the left side we have data sources on the right side we have data targets. And the first thing I want to show with equal them is, is a replication process and how it's done in equal them. We have sources targets and what we call replication groups. So in this environment we have an Oracle CDC source and the postures CDC source and we have a postures target. When you create a source in equal them. What we have to do is pretty much supply the credentials and, you know, an access details to the database. And of course we have a lot of advanced settings, like, you know, schema evolution settings which basically means what what should I do when a field is added at the source should I ignore that, should I replicate that all the way to the end, or to the target or should I do it like manually I only evolve the data capture process and alert you to kind of react to that. And then we have a bunch of more settings for performance aspects and so on and so on. But basically, if you create a source this is all you need to provide all the rest you should use the defaults otherwise needed. So I have created the Oracle source and the postures source so the next thing I want to do is create what we call a replication group. So for that I have five tables on the Oracle side waiting to be replicated to postures. So if I switch to my dbver, whoever you're familiar with it as a database client like a universal database line. So on the Oracle side here, I have these five tables that I want to replicate staging tables one to five. On the Oracle side, you can see each one of them at the moment has 500,000 records, and I want to replicate them to my process environment which at the moment does not have these tables. So I'm kind of starting from scratch here. So switching back to equilibrium. What I'll do here is I'll just create what we call a replication group because Oracle to postures. I'll select my source, which is in this case the Oracle source, and I'll select my target postures target. I'll select which schema I want to write the data to that I want to replicate to the equilibrium schema in the process database. And then all I have to do now is choose the tables I want to replicate. And for that I don't need to do that one by one. We have the concept of patterns. So I can choose one or more schemas. I did I want to replicate data from the Oracle database so I'll choose equilibrium for now. And let's start with just giving you know I want all tables. So I'll generate the list of tables. And now I see that this actually we have more tables than what I want to replicate. So I can add another pattern saying maybe I want to exclude all the tables that are called something TMP something. So if I repopulate here. We see that we have now less tables, but I still have two tables here that I don't want to replicate so either I create another pattern for them, or I just quickly manually exclude them, and you'll see them in the explicitly tables. So what I have now is the five tables I wanted to replicate. And the next step would be to validate that we have enough permissions both on the source and target to read and write those tables. So, in this case, we do have all the permissions so we can move on to the next phase of actually creating the replication group. As you see we have a new object here, our application group if I drill down into it. You see with that we have the five tables and in a second you'll see equilibrium starting to load data. This is the initial load data initial capture with starting to collect data from the source as you can see we're doing it in pretty high speed. Yep. This is fantastic but it brings up a question in my mind. You mentioned when you were setting up your replication group that the tables do not yet exist in Postgres. Does that mean that you actually interpret the DML, or not sorry, not the DML the DdL from Oracle your Oracle source to your Postgres to automatically create the tables. Exactly. So I'll show that in a second. So let's go back into Dbeaver. So now if I go into the Postgres, right, if I do a refresh here on the table, you'll see that I have all the five tables. And let's see what's how we're doing in terms of the load. So I need to, the connection is going to invalidate and reconnect in a second. We timed out in the meanwhile. So by the time we finish this query I do expect all the data already to be in Postgres. So not only we created the table we also loaded all the tables. So you see we have the five tables here all loaded with all the data right 500,000 records each. So yeah definitely JD we do interpret the DdL we converted to Postgres syntax and we create a tables if you choose to do so. And in this case we have chosen to do so. So we have all the tables set now we have the initial capture of the data there. So now let's do some stuff. If I go back by the way back to the UI you'll see that data stopped loading because naturally all the data was loaded. So we stopped reading. That was pretty quick. And again we can handle up to millions of events per second. In equilibrium very, very easily we've done that in for different customers. So, depending of course on resources hardware and so on. So the first thing I want to do here is in the source. I just chose one of the tables and I query table number one, where a certain column X will equal zero. And you'll see I don't have any such records. I go to if I go to the target I have the same query ready. Of course, nothing is here as well. I go ahead and I'll update, you know this table and I'll just update 5000 records. Right. So now if I query I have, I expect to have in the source 5000 tables, updated. If I go to the target, you'll see that they're already there. So in the few seconds, since I updated and switch to this tab, we replicated the 5000 changes already to the target. So this is the speed you should expect like 1000 or 10s of 1000s of changes per second, replicated from source to target so for any operational system. This is this is great right you can use your data in your in your target system in your data warehouse or data lake or any other system, pretty much as soon as the data is created in the source. I have a question on that. Sure. It is going to, I would guess explicitly qualify there's two parts to this question one, is there an assumption of a primary key. Yeah. So for application scenarios. We do require primary key because we do want to at the end of the day update the target based on the primary key to either insert up there or delete so we do need a primary key involved. But you can do other process without a primary key if you don't if you do not wish to update the data just offended. Yeah, and that that's actually a common requirement so if there's people online they're like well I don't have primary keys well if you're doing any kind of logical replication or logical decoding you're going to need it. And even if you were just using normal post replication that was logical. Before the second thing one thing you did mention logical, and that is the key here, if we have a physical primary key will use that. If you do not have a physical primary key you can still define what we call a user defined primary key and equal which is a logical primary key on in the source, which we can apply to the target. Oh good so that the second part of that would be in this really only applies to update and delete so I'm assuming that you're not creating some kind of long running update dml you're just updating the values based on the primary key or deleting the values based on the primary Exactly. Exactly. Good that's very efficient. Yeah, otherwise we cannot be real time in any manner. Yeah. Exactly. So, so we've seen that now I want to show a bit another example of schema evolution of adding a column. So, in the Oracle system I'll just add a column. You can take a look in the postress right table one. If I look at the list of columns. I'll open the columns just refresh for sure. And you'll see that with the last column here is called cat old mouse, whatever. Same of course applies to the source because it's the same table we just replicated it, but now what I want to do is, I want to add a new column, and I'll call it in a very, you know, a very unique way I'll call it new call new column. I'll just update that column for just update one row with that column. That's, of course on the Oracle side. If I go to the postress side right here, and I'll refresh. You'll see that now we have the new column on the target as well. So we don't only replicate DML in real time we also replicate DDL in real time and like JD mentioned. This is actually translated from the Oracle DDL that happened to the Postgres DDL. That's a fantastic feature. Postgres current Postgres logical replication without its own add ons does not support that you would actually have to modify it by hand. And the fact that we can do that live from Oracle. That's a very powerful feature that I don't think people, I don't think that should be undersold. Let's put it that way because it takes a lot of effort out of the DBA's hands and having to worry about all the lovely application developers that are arbitrary arbitrarily changing the schema. Yeah, for sure. That is, I mean, when you talk about replication, you want your application process to run 24 seven and you wanted to succeed. I do need the data in real time in the target. So, in order to not break the replication. Yeah, you have to propagate schema changes. Yeah, right. And I did just get a direct question on this which is appropriate. We're assuming that it's not just legacy Oracle that supported it's any of your supported sources that you will support the DDL replication. Yeah, sure, sure. Basically, DDLs are for, you know, databases or any database source can be replicated to any database target will do the conversion in between. So I want to show one more thing before we open up for questions, I think, and then we talked about replication. And you see how easy it is to, to create replication groups in equilibrium replicate any number of tables any number of changes from the source to the target. Everything is also monitored. So you see the status is here everything is has a status if something breaks, if I go in each replication group object has a status. If it changes for some reason from active to pause or error or whatever I'll get an email that can be configured. We have a lot of metrics going on that you can we have a metric explorer. I mean you have a lot of metrics in the UI, but you also have an add on, which is Grafana, if you're familiar, which is our metric viewer that stores hundreds and hundreds of nodes if you want to kind of troubleshoot and analyze them. But, but obviously what you really want to do is do your actual work and get notified via email if something breaks, and that is out of the box with equal. The last thing I wanted to show is just like in two minutes is we talked about replication mode but equal and also have another mode, and that is the real time ETL or rich on dating gestion mode where you can also do some transformations. So just to quickly show you that. If I go into the Oracle source. I, you see the, the tables we brought in via the replication group are created as what we call streams. And the streams are processed by what we call flows. The flows we use for application are, as you expect source to target. But if I go ahead and create my, my own flow. I can then really leverage equivalence ETL or transformation capability. So if I just grab one of the tables. You can see that and this is where the zero coding part comes in. I have a bunch of operators that I can perform on the data I won't cover all of them I will just choose one of them just transform operator. So, although I got the data and here's another cool feature I can preview the data so I get a glimpse of the data coming in from the source so I can, you know, feel the data and kind of know how to transform that. So, I have the schema coming in, and I can decide to add a new column. Right. And I want to create a new column every time data comes in I want to populate this column and push it to the target. So for example, if I want to concatenate, for example, two different fields. I don't need to write code I just double click on concatenate. I double click on a bunch of field, I better choose string fields. And I actually can concatenate a field with another text. Right. And this actually creates a new field in real time the field is populated in real time, and then I can write it to my target. So it doesn't have to be a pure application use case. It can actually be transformed as well and again we have a lot of different capabilities for this part. You can hear because it's not automated you can create you can generate the create table yourself. So, again, we can still even though it's not automated we can still help you generate the create statement which is adapted to Postgres, right, although it originated from Oracle. Right, so if I change the table name it will reflect here and then I can just execute it in the target. And then there's a lot of more capabilities you can do in transformation, like aggregating data, like doing lookups and enrichment, like logging errors logical errors in the flow and a lot a lot of other capabilities that I think will save for another webinar in the future. So JD, that is what I was able to kind of, you know, cover in the timeframe. I'll hand it back to you. We did have another question come up which I think is interesting. How do we handle triggers and indexes. So if your source has a series of triggers or source of indexes are triggers replicated or indexes replicated or both or one or something like that. Good question. So, Equalum is about data replication and not necessarily schema or database replication. Equalum replicates data in real time. So it's not a database migration tool per se it replicates the data. So if you want to replicate your indexes and your code your stored procedures and stuff. You might want to use a one time tool to create your schema but you then need Equalum to kind of load your initial data and keep databases in sync for the migration process. So we do not replicate indexes because more often than not indexes on the source will be different than indexes on the target because the purpose of the system is different. That's true. Especially if you're migrating from say an OLTP to OLAP database or something like that. Exactly. It's a whole different structure, different indexes and so on. So we do not replicate although we can very easily do that. We find that, you know, not a requirement for most use cases. So we replicate the data and of course DDL but we will not replicate your stored procedures and indexes because that's up for you up to you to decide how you want to use them in the term. Okay, so we have we have a question is that is this a good tool for pulling in all Oracle databases we have into our new Postgres systems. Now I actually think I can answer this. I would say yes it is. It's an excellent tool for that. Mainly because you can have multiple ingestion sources as well as destinations. And as you do your trend it also allows you to do your transformations which is very important. Oracle doesn't have, for example, the Oracle number format. There's no equivalent in Postgres because Postgres is strictly tight. And there's also other things that you might be doing. For example, you might have a constrained column to simulate Boolean, whereas Postgres has an actual Boolean. So being able to live transform your Oracle data and ingest it into Postgres in the way that Postgres is going to expect it to be would be highly valuable. Plus, since you can't just do an overnight transformation a lot of times, you're in a situation where you are live replicating for a period of time sometimes a long period of time, as the applications are being tested against both sources. As those applications change and DDL changes those DDL changes are also going to automatically replicates Postgres. Yeah, JD, I think you covered it the best possible. Thank you. Awesome. Well, a qualm can be found at www.equalum.io and they also have the ability to download a demo for your testing purposes. Your information will be provided to a column so that you guys can start a relationship and hopefully build something out to get everything off of legacy Oracle. Everyone have a great day and thanks for attending. Thank you everyone.