 Good morning everyone, I was hoping a little larger crowd than this, but yeah whatever it is. Thank you. Yeah, thank you. Thank you very much. So, we will be talking about a lot of logical replication in Postgres, multi-master replication you know why do we need multi-master replication in Postgres and then some of the replication nuances like conflict resolution and so on and so forth, right. Let us delve into this. So why do we need logical replication? Some of the folks that know about the replication methodologies available in Postgres, there is physical streaming replication, logical trigger based replication which is kind of a legacy and we also have some of the asynchronous replication technologies that are coming into the mainstream now of late, right. We require now the native logical replication that were becoming part and parcel of Postgres from PG-10, right. So some of the use cases where a lot of our database engineers use logical replication is to achieve no zero downtime or no as less downtime as possible when you are doing major upgrades between database versions, right. Say for example, you are on a non-supported 9.4, right and then you would like to upgrade to PG-10, 11 or no PG-15, so for instance, right. So you will be able to use the native logical replication and do a major upgrade with zero downtime, right. And logical replication works in publisher and subscriber model which means so you can have publishers publishing your data sets and data sources to a ton of subscribers, right. There could be more than one subscriber. Some of the use cases that we have seen on the publisher and subscriber model is you can have one of, setting up one of your entire HA system with the logical replication, right. And then you can pick and choose what tables you would want to have as part of logical replication, right. So you could do your data warehousing use cases with logical replication. You could do a lot of lake houses and the modern data stack that Mahbub was talking about, right. And then with replication in logical versus physical, right, it is more of the entire database or the instance versus in logical it is database by database, right. You could pick and choose schema by schema, table by table and stuff, right. And with PG-14 and 15, there is row level filtering, you can have a specific column to be part of the publisher and then subscriber will be able to consume them, right. Under the hood it uses logical decoding, now there are some super cool low level APIs that does that task now using the logical decoding, right. And now we slowly fast forward to the multi master replication and then what was the history behind multi master and multi active systems that were available in Postgres ecosystem, right. We had one that was based off of 9.4 and 9.6 that was the BDR-1 the first and foremost version of bidirectional replication, BDR stands for bidirectional replication, right. And second quadrant and now the erstwhile second quadrant and you know the EDV folks have something called as Postgres distributed, right. That is also one of the bidirectional slash multi master replication solutions available, right. And then in a BDR-1 there was BDR-2 and BDR-3 which were proprietary slash closed source ones, right. Now why are we looking at multi master, why are we looking at some of the multi active solutions, right. So we are talking about computing use cases a lot in this case, right. So if we look at some of the stack that we are trying to look at here, right. So we are getting the user closer to the system, right closer to the compute, closer to the edge network, right. You got variables, you have got mobile devices, you have got the entire application stack on your right, right. And then these are some of the smart home systems, the IoT devices and stuff, right. So what are we trying to do? We are getting the compute, we are getting the data closer to the system, closer to the users, right. And then we are also working with a few CDNs, right, you know, content data networks like, you know, Cloudflare, Fastly's and you know, I was also talking to a couple of folks from Warnish software, right, they are here in, in, in Forsesia. All of these guys have the static pages that are available and then made available on the edge. What we are missing is the data piece of it, right. Now how do we get the database closer to this edge compute network, right, edge cases, right. That's what, you know, we are trying to solve with PG edge, right. One of the reasons why we had also named the company as PG edge, I would say, right. Now, what's the take on Postgres, right, how do we get integrated with Postgres ecosystem altogether, right. So, PG edge has got two products, one is the PG edge platform, PG edge platform is a completely standard Postgres and 100 percent open, right. If you take a look at the platform, per se, right, it's got the standard Postgres engine, right. So, we start supporting from PG 15, if there are use cases, you know, we will be able to support PG 14 also, right. The right hand side of the slide is more of the standard Postgres offering, right. Now, Postgres has this super awesome extensibility model, right. So, we've got Postgres, which works primarily on the REST APIs and then, you know, there are extensions, right, that I was talking about, right. So, we have already made these 20 plus extensions available on the PG edge platform. So, you go ahead and download the binaries from PG edge dot com. So, you get the entire offering for free, right. So, you'll be able to go ahead and do your development activities, right, and get your hands dirty with multi master application, right. So, one, I mean, two components that are part of the platform are the node control and the cluster control CLIs, right. Both of these are the armory behind, I mean, working under the hood, you know, that is enabling the entire cluster orchestration that is enabling the entire PG edge platform, right. And the extension, you know, the extension that enables the Postgres cluster to be multi master is SPOC, which is the multi active replication and any multi master replication solution, you know, would require a super solid conflict resolution, conflict avoidance in place, right. So, SPOC brings to the table the multi active and multi master with the conflict resolution and then, you know, keeping things as simple as possible, right. So, there are multiple masters writing databases, multiple sources writing and then, you know, you have under the hood a strong algorithms, you know, strong APIs taking care of the conflict avoidance and conflict resolutions. That is the part that SPOC brings to the Postgres platform, right. And apart from, you know, the PG edge platform, right, there is another product called as PG edge, which will take a look, right. But now, if you take a look at, you know, the PG edge developed and the Postgres community developed, these are the only two components, right. Node CTL and cluster control, that is the intelligence behind the cluster configuration and then the standard configuration that gets set up as soon as, you know, you run the PG edge platform, right. So, the adoption or from an existing Postgres QL clusters, right. Now, how do you go ahead and incorporate PG edge or how do you adopt Postgres plus the PG edge? These are the two components that you would require, right. The entire components and all of them are PG or the Postgres QL community developed software, right. So, this is the only two components, which is this SPOC and the Node CTL and cluster CTL that you would want to attach to your cluster and then, you know, make that cluster, you know, edge aware and multi-master and multi-active, right. So, what PG edge platform brings to the table, right. So, all of the features are part and parcel of the fully distributed Postgres QL, right. And then it is available for you guys to go ahead and download, put it on development machines, put it on your production and stuff, right. And we also have enterprise support available, right. So, that is where we have our subscription based support available from PG edge and, you know, some of the eminent Postgres contributors being part of that enterprise support, right. And, you know, every product in the Postgres ecosystem, you know, that is bringing, you know, functionality, future set into the system will have a licensing model, right. So, what is the licensing model that we have as part of PG edge, right. It is a community license. More of the licensing is around the confluent, right. So, just like Kafka, that which is a very good example to take, right. And we will be able to, you know, download Spark and then, you know, just attach this Spark extension to your, you know, already running database, right. And you could just use it on production, right. There is absolutely no licensing around, you know, or restrictions around using the system. And the only caveat or the only catch here is none of the cloud providers will be able to package our product and then host it on their cloud offerings like an RDS or Azure for Postgres here, right. That is why we had the pun, sorry, AWS, right. And this is the cloud SaaS software that I was talking about, right. So, this is a fully managed database where you will be able to go ahead and set up on AWS and Azure at the moment, right. And GCP and, you know, Google cloud support is just around the corner, probably in a quarter or two we should be able to get up and running on Google cloud also, right. And with the PG Edge, right, so PG Edge platform, so you will be able to go ahead and do an on-prem installation, on-prem setup, you know, for your current commodity hardware or use your cloud, use your AWS account and then, you know, hop on your, you know, IAM and then, you know, grab the EC2 instance and set up the PG Edge platform code, right. So, it is very easy for us to go ahead and, you know, incorporate and then, you know, set up the PG Edge platform. And the access to both PG Edge platform and PG Edge cloud, PG Edge platform obviously, you know, you have got CLIs, you know, you have got web interfaces that you can go ahead and hook it up. And then, you know, PG Edge platform also comes with a super solid monitoring system in place, right. So, we have got Prometheus plus Grafana as one of our monitoring, enterprise monitoring tools that are incorporated and, you know, integrated with PG Edge and PG Cloud, right. So, we will be able to take a look at some of the PG Cloud, PG Edge Cloud instance demo screenshots, right. So, if I summarize the whole PG Edge, you know, the whole feature set or the interesting facts and figures about the PG Edge, right. So, we will have low latency because we are closer to the user, right. The database systems are closer to the user, meaning you are writing to the nearest available node, right. So, you just have to have your application code not talking and, you know, being aware of what is the nearest database node available in the cluster, right. And, you know, that solves a lot of your, you know, latency problems and then the latency issues where a plus or minus 50 to 100 milliseconds that, you know, we will be able to save, right. And then we are talking about millions and millions of transactions per second. And then, you know, millions and millions of transactions that are happening across, right. So, that is a pretty good trade off, I will say, right. If you are grabbing the 50 to 100 milliseconds of your connection request, right. And then the ultra high availability model that we, I mean, specifically call it as ultra high available because you have got multi master nodes and all of the multi master nodes will have a logical replica supporting them, right. So, a logical replica around how do we set up fallback instance, right. So, you have got a, I mean, like I spoke about the logical replication, you can set up the entire instances as a logical replica, right. And you will also be able to set up your own witness nodes around the clouds availability and so on and so forth, right. And then the data residency is another very important use case that we are seeing these days, right. So, you want to make sure the data is residing in your own continent, in your own ecosystem, right. So, that is another one where we implement something called as PII enabled partitions, right. So, you can have multiple partitions in place and then all of those data sets could be PII enabled, right. So, that is already available, you know, baked into the product, baked into the PGH both cloud and PGH platform, right. And optimized for the network edge, right, like I mentioned about. So, your data set and then your application layer are, I mean, your application layers are, you know, all of them are HTPAs and HTVDs, right. So, all of them will be able to go ahead and take a read, write access to your nodes that are closer to the network edge, right. And fully managed to debass, right, RPG cloud. So, I have got some of the folks running the show there, taking care of the support ecosystem there, right. And then PGH, you can access it via web, you will be able to do REST API calls, you will be able to use the DPA friendly client, main interfaces CLIs and stuff, right. PGH platform is more of the CLI product offering of it, right, which is completely open. The one, the extension that empowers the whole edge computing and bringing about the multi master of application into the system is this POG, right. This is an extension that, you know, you could go on the GitHub and see the code and stuff, right. So, this allows you to do asynchronous replication between all your master nodes, right. And Spark also bakes in the predefined monitoring, the data dictionary, the catalog, because it is completely based off of the Postgres, the data dictionary and the catalog views are already available in them, right. Like I said, now, with every multi master application solution, the conflict resolution and, you know, the error handling that has to be within this system is pretty important, right. Which means you are, you have got master nodes across, you know, three or five, right. And then all of the nodes are writing and then, you know, you should have the conflict avoidance first place. And then, you know, if there is a conflict, how do we resolve it? How do we resolve those conflicts, right? The conflict resolution model that we have available is, so you could, you could go ahead and use the apply remote, the last update wins or the first update wins, right. So, you will be able to go ahead and configure according to your data needs, right. So, like we say understand your data, understand the problem and then look at what is the exact conflict resolution that you would want to incorporate. And then, it is a simple example of, you know, how do we look at first update wins conflict resolution, right. So, these are two nodes. So, we are talking about this as only one transaction. So, imagine a transaction volume of around 12,000, you know, TPS, right, 12,000 transactions per second. And all of these happening in a, you know, more streamlined and more foolproof manner, right. So, we are, we are looking at node one and node two. So, up until now, PG Edge supports five nodes. So, you will be able to set up five different nodes and on five different regions on AWS and Azure. And then, you know, for conflict avoidance, you know, we have not created any CRDTs. No CRDTs stand for conflict-free replication data types, right. So, we have a simple implementation of grabbing the old value and then, you know, whatever the updated value and you know, how do we bake those node two values and then, you know, grab the exact result and then, you know, have it eventually propagated across all of the PG nodes, right, the PG Edge nodes, right. And the functionality that, you know, we have is simply making sure the table has got log old value equals to true. Right, which means that whatever is the column, right, basically, this is the primary key column that we would want to make sure that has the log underscore old underscore value. What it enables is it makes sure we are having, it's explained in the next. So, first we will grab the old value of the column that is captured, right. And then second, the transaction that is going to update the value and then, you know, both of them are computed and you will get the source of truth that is propagated and eventually consistent across all of the nodes. So, at a typical deployment of a PG Edge, right, so you will be able to see a lot of hub nodes available here, right. So, this is one availability zone, right. We have got one in Europe, one in the Australia region, right. All of the hub nodes can have the logical replicas for a high availability standpoint, right. That's why we say ultra high availability. And, you know, right now I said, you know, the AWS and Azure are the ones, you know, we will be able to set up the servers on and do the deployment. These are, you know, when you hop on the PG Edge dot com, right, you will be able to create your own clusters and then, you know, see how things work out and, you know, how do we set up multi-region database nodes across in PG Edge. So, these are the UI screenshots that I have grabbed from our PG Edge system. And you will be able to, like I said, you know, one of the important things that is already available with PG Edge is the monitoring system, right. So, you will be able to have the strong and, you know, in price level monitoring system available with Prometheus and Grafana, right. So, that's another thing, which is available on the PG Edge cloud dashboards. You will be able to see and make sure you've got the database instances being monitored on live, right. And then the security modus operandi of PG Edge is, you know, pretty much the owners is on the user, right. So, bring your own cloud accounts and then, you will be able to go ahead and take care of the VPC pairing, you know, what do you want to do with, you know, how much of cost you would want to do, right. All of that stuff that, you know, that is associated to a cloud service provider, you will be having complete control, right. We've not wanted to be resellers of, you know, AWS or Azure, right. So, we wanted you to be having the pick and choice of what cloud provider you would want to work with. And then, you know, bring your account and we will be able to set up those, set up on those regions and cloud infrastructure, right. And every operation that you would perform on the PG Edge cloud, so you will be able to audit and then you will be able to go ahead and take a look at any compliance checks that, you know, that is part of parcel of, you know, a lot of cloud offering products, right. And these are some of the useful links I have laid out. So, now, go ahead and, you know, hop on the githubpgh.com. I mean, pgh.com or, you know, so there are some cool blogs that are available on pgh.com. And the one blog that we have written is the Distributed Post Classical with Cloudflare and some of the other CDNs that we are currently working with, right. And that's something that we are pretty excited about and we'll be working on as part of our next coming, you know, few weeks. And if you have any questions, I'm around the whole day in the conference. Feel free to write, you know, touch base with me. Any questions? Yes. So, how does the client figure out what is the nearest hub they should connect to? What's the process? So, if we take an example of the Cloudflare, right, so Cloudflare has got pages, Cloudflare workers and then, you know, at the end it is database, right. So, Cloudflare workers, so we are working with Cloudflare, you know, to have a specific code in place as part of workers. The workers will have somewhere around code inside the workers, right, which is a simple NodeJS code, right. The NodeJS code will be able to use the Geolibrary and then, you know, pick up the exact closest node available. That's one of the CDNs that, you know, we are working with. Fastly has, you know, something called as, you know, point of presence, you know, FastlyPOP and all of these CDNs. Have you designed some sort of a rule system for data residency so you can build the logic about what stays local, what gets replicated? Absolutely, yeah, we have it as part of, you know, there is a whole bunch of infrastructure available for you to have API data, right. So, you can have your API partitions, no specifically residing in one of your regions, right. So, say for example, the GDPR plus the EU, right. So, you will be able to go ahead and see what requests are coming from the EU and then, you know, all those requests are routed to the EU region and stuff. Any more questions? Okay, that's okay. Thank you very much, Hari. Thank you. Let's thank our speaker.