Scaling Databases For Global Serverless Applications

Bookmark

This workshop discusses the challenges Enterprises are facing when scaling the data tier to support multi-region deployments and serverless environments. Serverless edge functions and lightweight container orchestration enables applications and business logic to be easily deployed globally, often leaving the database as the latency and scaling bottleneck.


Join us to understand how PolyScale.ai solves these scaling challenges intelligently caching database data at the edge, without sacrificing transactionality or consistency. Get hands on with PolyScale for implementation, query observability and global latency testing with edge functions.


Table of contents

  •         - Introduction to PolyScale.ai
  •         - Enterprise Data Gravity
  •         - Why data scaling is hard
  •         - Options for Scaling the data tier
  •         - Database Observability
  •         - Cache Management AI
  •         - Hands on with PolyScale.ai



Transcription


Yeah, welcome everybody. I can still see a few people coming in, but we'll get kicked off anyway. So welcome to this no Congress talk on scaling databases for global serverless applications. And let's just show the agenda for today. Just a couple of housekeeping rules. Everybody feel free to use the chat. You can also unmute. There's quite a lot of people on this. So, you know, stay muted if you're not talking, but please unmute yourself ask questions. Let's make this as interactive as possible, because I think there's lots we can learn by by collaborating our questions. So yeah, feel free to use the chat, but obviously unmute and introduce yourself and by all means jump in at any point if you have questions. Those are very welcome. So yeah, hopefully everybody can hear me okay. And this is our agenda for today. So quick bit about myself. I'm the founder of poly scale. And my background's really been in working with sort of large data companies and database companies. And I've sort of been in the solution architecture and sales engineering space for many years. And sort of the last few companies I was at, you know, alfresco is a was an open source document management company. So we dealt with very large amounts of data repositories for specifically for documents and web content management. data sift was one of the early adopters of the Twitter fire hose and ingested all of Twitter's data, and later on worked with Facebook and LinkedIn to ingest all of that data and serve insights in a privacy safe way. And then from there, I moved to elastic here in the Bay Area in San Francisco, where I was working with some large enterprises with the elastic solution and scaling those. And, and then before founding poly scale, I was at a company called Rockset, which is a cloud based database for real time analytics. So throughout that sort of, you know, this these last years, I've always been focused on managing large volumes of data and, and understanding, you know, how to scale those sort of globally, that's really been the challenges I've been working on. But today, yeah, we've got a great talk lined up, I'm going to introduce you to obviously to poly scale, and we'll get hands on with that for people that want to actually test it out. And I'm going to talk a bit about the challenges really in the enterprise and smaller businesses as well around managing data and scaling data. And why is that hard? Why is it hard to move data to different regions and to, you know, keep and maintain your transactionality? And so we're also going to talk about what are your options? You know, what do people do today to kind of scale these, these database systems and data platforms? And then as I mentioned, we'll dig into poly scale and what poly scale is and how it works. And as I say, everyone's welcome to get hands on and we got some code to, to play with and get started with. So yeah, as I say, everybody, everybody who would, you know, any questions, feel free to chime in, unmute yourself, introduce yourself, you know, very welcome to take questions. So really, the premise for, you know, why poly scale exists and why, you know, our focus is really scaling stateful cloud native data is hard. So anyone who's been in a, in a role where you've had to, you know, take a database, for example, and scale that to different countries or even just scale it independently, you know, you'll understand the challenges of, of doing that. And there's a whole bunch of reasons around like why that is hard from things on the cap theorem lines to, you know, maintaining my transactionality. You know, how do I shard my data? Where does that reside? And then how do I sort of manage just the, you know, the laws of physics around accessing that in a, in a low latency environment across continents, for example. So great example that we've got people from, you know, all parts of the planet dialed in today and making data fast for everyone is a hard and complex thing. And specifically here, we're talking also about cloud native data. So what happens when you are in a situation where, you know, you have a data center outage, you know, one region goes down or a part or component of your architecture goes down. You know, how do you support those environments? And that's what makes it hard. It's maintaining that state and it's doing that in an unforgiving environment like, like the cloud. So, you know, I talk a lot about this concept of enterprise data gravity. And, you know, kind of what is that? And how does it affect us? And, you know, the reality is data is being created everywhere. And it can be, you know, across multiple disparate systems. And inside a single enterprise, there are likely many, many different data persistence layers. It could be things from data lakes, you know, databases, warehouses. And that stuff is being created, you know, all day, every day. It's just an ongoing, it's an ongoing thing. With sort of AI and machine learning, you know, sensor data and iot, that's just accelerating massively. So what we, what tends to happen is within enterprises, you know, more and more applications want to use that data. And, you know, there are, you know, people are requesting access to that data from different departments, from different locations. And that then gives us this inability to move the data. We find ourselves kind of shackled to once somebody is using, let's say we have a large transactional database that says Postgres, and that's running from a data center in New York. And we now have, you know, large numbers of users actually actively using that, it becomes harder and harder to kind of access that data in different locations and move that data. So location, location becomes critical depending on where your users are. And then the other sort of big consideration around data and usage is, obviously, what are the data regulations around this? Things like privacy and compliance, you know, PII data, what are you storing in what countries? You know, is it GDPR compliant? And this is becoming more and more is incredibly critical today, but it's only becoming more critical as we as we progress with these data systems. And then lastly, you know, we've got to consider global growth. So it could be, you know, a simple web application, we find that we now have a growing audience that are spanning different countries or parts of countries. And how do we make sure they can access that data? And how do we deal with that global growth? And the same within, you know, sort of a non-customer facing application, maybe it's something like a BI environment whereby people are accessing internal intelligence data using tools like ClickTech and, you know, Tableau. So same types of problems. We're putting new offices in different locations. People are all working from home, working remotely. How do we support that growth? And that's really the essence of the problems that come with sort of data gravity. So I think probably a lot of people on this, this talk will be very familiar with the application tier as a lot of agility. Like if I said to everyone on this call, like how would you deploy a web app? I think we have a lot of different options. And if I said, how do I deploy a web app to different regions? I think there's a huge number of options as well. And, you know, I kind of think about this, you know, the content and the code, so static content and public content, and then so static content and business logic can easily be replicated locally. We can now, you know, we live in an era where we have these amazing companies like, you know, Netlify and Basel who can, you know, push my application logic and my static content everywhere and I can run functions at the edge. And I can knit that together with, you know, a simple load balancing plan that will allow me to resolve to my closest application server. So it's really quite achievable now for any size of business or individual just so, you know, an indie hacker to be able to set up global load balancing. We can deploy to CDNs for our static content and our functions. And we're also seeing the ability to, you know, these new players pop up like Fly and Section who allow you to containerize your code and push that everywhere into multiple regions. So as far as the business logic and your static content goes, there really is a huge amount of flexibility. And that's a great space to be in. I'll just pause there. Any questions before we move on? Anything in the chat or anyone wants to chime in with a question? Good. I guess that's pretty straightforward at the moment. So hopefully all good. Hi, I put a check question in the chat. So essentially the question is in terms of compliance, what if you have a user in EU but the server and, you know, the product or service in US, how do we deal with the data? Yeah, it's a good question. And I'm going to tell you a little later how Polyscale deals with that. But at a high level, you know, enterprises are defining the policies around where data can reside. And there's a huge industry in auditing and compliance around, you know, what data is stored where, and you have to adhere to those policies. Now products are making that easier and easier. And, you know, in kind of a basic sort of web application world, you may, you know, have a block list of locations that you want to deploy that data to. Now it gets more complex if you're thinking around, you know, you've got global audiences who reside in certain countries and accessing data in other countries. So for example, if I'm a resident in, you know, Germany, for example, and I'm using a service in North America, is that, you know, am I okay with storing my data outside of Germany or must it be stored in Germany? So I think these are things that you must build into your product from kind of from day one. I think these are absolutely critical if you're storing customers' data. You have to, you know, start with that mentality of, you know, what is the, what are the policies that we need to adhere to? So yeah, I'll show you, you know, sort of how we support that with Poliscale. But really, it's something that, you know, you've got to build into your products from early stages. And there's a lot of products now out there that provide frameworks that you can interact with and integrate with to make that easier. So from a compliance perspective, you go to a single location, you can easily audit what data is being stored where. And that's kind of critical for, you know, software compliance and other forms of compliance. So yeah, as I was sort of talking about here, you know, we've got a lot of agility in kind of that business logic space in the content and, you know, the CDN market has really made this trivial now for us to deploy everywhere. But the data-driven apps, you know, making those fast globally still remains to be complex and expensive. So it's one thing to kind of make a data-driven app fast in a single location. But as soon as we start thinking about doing that everywhere, we really run into these complex, you know, complexity issues and expense problems. And the expense can be everything from, you know, developers' time, from architects' time, you know, using different types of databases, data systems, you know, could be your aws and your storage costs. So and the complexities are typically ongoing. So it's not simply a case of let's start up a database and let's put a couple of read replicas in and then we'll forget about it. It's more a case of, you know, what happens when they start lagging and get out of sync? What's the implications on my application tier? Do I need to start separating out my reads and my writes in my code layer? So there's sort of complexities and expense all around, you know, all parts of the business. So the global, you know, why is this hard? Like the global data challenges and, you know, one of the core ones here is really sort of consistency and transactionality. So, you know, the classic example is I'm running an e-commerce website that may be being served from, let's say, the East Coast of the States, New York. I go and buy a product, you know, someone else on the planet shouldn't be able to go and buy that exact same product because that may well be out of stock or, you know, in simpler terms, wherever people are actually witnessing what the stock levels are, those should be accurate in real time. They should be consistent. So, you know, you've got to decide and one of the trade-offs here is like, are we sort of using asset compliance systems versus eventually consistent systems? And really, you know, that depends on the use case, you know, what are your tolerances for different semantics here? And the classic one, which obviously the CDN space has done an amazing job at looking at is that latency one, the classic speed of light. How do I serve a customer who's in a location who is far away from my data? And then the other one is sort of, I've talked here a little bit about sort of fast-lived TCP connections, but really it could be anything that is your data platform is dependent on. So, you know, in sort of a more transactional database, Postgres, MySQL and whatever, you know, TCP connections really matter and that hits your scalability challenges. So, what if you're using things like, you know, functions that run at the edge or, you know, aws lambda, things that are creating a high number of short-lived connections? How do I scale those and how do I support those? So, these are some of the core challenges that people face with scaling into different regions. So, you know, how did we address this today? Like if I said to kind of people on this call, like I've got a web application and let's just sort of tail this down to web applications and let's say, you know, I need to make that fast kind of in the US and I need to make that fast in Europe as well. Like how would we do that? And I think the core things that I've seen in my career and I see quite regularly are people turn to application-level caching. So, people are going to be really comfortable in writing code that will save that data. We can reuse it. We can hydrate it. We can evict it from the cache intelligently. We could use tools like Redis or Memcache that scale nicely and we can also share state with these if we want to. So, these are sort of the go-to areas for application caching. Now, there's pros and cons of every approach and I just want to be clear here that I'm not sort of, you know, I've seen all of these work great in production and but I've also seen, you know, there is cost and complexity that comes with all of them. So, the classic one with sort of application caching is you need to write that code, right? That's not a sort of typically not a quick thing depending on how large or complex your web application is and if your data systems are scaling multiple platforms, let's say we have a, you know, a real estate website and we're going out to various different data repositories to build data around, you know, the property history and the current mortgage rates. They may have different caching policies that you need to adhere to within your application. And then on sort of an ongoing basis, you would, you know, every feature that you add to your application, you potentially need to, you know, incorporate your caching layer as well. So, it's kind of an ongoing thing that, you know, can be abstracted out nicely but there is an overhead and, you know, tell me, I'd love to hear chats and comments but, you know, anyone who's actually written a caching layer to a reasonable size application, it can get complex really quickly. So, and then you obviously have the knock-on effect of, you know, communicating how that's working to the rest of the engineering team as well. So, definitely pros and cons of all of these. We're also seeing, you know, the last few years we're seeing some amazing sort of global databases pop up like Cockroach and Yugo Byte, you know, databases that are focused on that global challenge, you know, how do we efficiently shard, where do we do our transactions, you could configure and define all of that behavior, which is incredible and, you know, I'm a big fan of these systems and what is often a challenge in the enterprise is the proposition of, hey, go migrate to database X, you know, we know that database X can do this for you, let's go and migrate off of what you're currently using to this database and that may well be an option if it's a brand new project, that could be, you know, no problem at all, but in, again, in larger enterprises or even smaller businesses, the proposition of migrating a database is non-trivial, you know, are the transactional semantics the same, is my query language the same, has it got the same features, is it, you know, do I need SQL? It's typically a large process to go and migrate an entire database, but again, you know, if that's right for your solution, then that's the right way to go, pick the right tool for the job. Now what I see a lot of and I've seen a lot over the last few years is kind of, you know, the polyglot data tier and I think this is, this is accurate for most businesses now that have multiple repositories for doing very, you know, using various tools to do different things and what I'm talking about specifically here is if we say, let's assume we have a large web application and, you know, we now need to start accelerating and making things faster, we'll take, you know, typically one way to approach this is you take your slowest feature, what's the one that's really top of the product manager's list around performance for your customers, is there something that really bites them every day, you know, you'll get that from your APM analysis, you know, what's the customer satisfaction, is it specific page, you know, I know, for example, I log into my unnamed cell phone provider account and things are incredibly slow. I just want to look at my bill for this month and last month and, you know, what numbers, how many messages have I sent and how much data have I used and that stuff's all so slow and it's going and pulling that from a remote location, maybe the database is busy, maybe it's overloaded, maybe I've done that in my lunch hour, so we're seeing spikes of load at that period, so it's a, you know, a common practice to then say, right, let's take just a single feature and let's break that out from our platform and start scaling that independently and that can be as extreme as, okay, let's go and use a brand new data store to actually support that feature and then you get into the complexities of things like, well, how do we maintain state with that external data store? Maybe we need to use things like change data capture streams to populate other data sources and a great example here is, you know, maybe I've got a transactional database, something like MySQL and I want to populate a search engine when things change and you can use things like change data capture to do that, but let's take an example here and it's a great way to think about sort of breaking your monolith out into microservices, so maybe we want to take a specific function and run that at the edge and maybe we want to start using something like a key value store offered by, you know, one of the many CDM providers, so now I'm in a situation where I've got a kind of a transactional database and I've got a key value store and one runs at the edge and one's centralized and again, that could be a great solution, but equally you're adding in a lot of potential complexity into that situation, but we see this a lot, people are breaking up those features and using the right tool for the job and as I say at the bottom, right, these are all valid, these are all valid, useful today and, you know, the other one I sort of haven't talked about really in this list is kind of database read replicas is an obvious one, so, you know, I've got a central location and I want to start supporting customers or getting that latency down in a different geographic region, you know, your hyperscalers make that super easy today, I can go click a couple of buttons and I can deploy a read replica, so again, another good option depending on where you need to scale and depending on the behavior. So, yeah, a quick introduction to polyscale and kind of where do we fit into this world and what are we and this is a bit of a mouthful, but we're, you know, a no-code database edge cache that distributes data and query compute closer to the user, so, you know, at a node conference that may sound like a strange thing, but we're a no-code application, the idea being that our focus and our real driver behind the platform is that as a developer, we don't want you to do anything, you shouldn't have to think about, you know, implementing caching and speeding up your data layer and managing like time to live values and what queries are expensive and how does that change over time, so our whole focus is, you know, what I would call plug and play, we want you to be able to plug in polyscale into your data tier and nothing changes within your environment, and what I mean by nothing changing is, I mean, you're not having to change your query language, you're not having to migrate your database, you're not having to scale anything differently, your transactionality stays the same, and that's really our focus, so what we do is, you know, if you're familiar with a CDN, a similar concept, and we actually cache database data at the edge or closer to the user, but as well as the data itself, we also offer the compute itself, so if I want to run a SQL query that's unique, that will actually execute against polyscales pops or point of presence and return you the data from polyscale if we have it in the cache, so we shift the query compute and the data closer to the user, so very, very similar to a CDN in that we, you know, we have global points of presence around the world, and, you know, our focus is making the data tier as low latency as possible and keeping the costs and complexity low, so as I've sort of, you know, gone through in the previous slides is there are numerous ways to scale your database and, you know, caching may or may not be a good fit for you, but our focus is really on making the complexity as simple as possible, so plug and plays is really what our driver is. So if we kind of, like, peel that onion back a bit on what is polyscale and why is this useful to me as a developer, and, you know, we obsess about the developer and operator experience, this top line up here, and, you know, we think a lot about what is that, what, you know, everyone in our company has sort of been in this position of having to build these systems and understand them and support them in their history, so we're absolutely fanatical about making this as effortless as possible, and the way we sort of focus on this is to see, well, what costs and complexities can we abstract away? What are those things that are tedious or hard for a developer to do or a devops engineer to do, and how can we bring those away from that situation and make those easily achievable? So, you know, the first things first is we integrate, or polyscale can integrate in minutes, literally, so I'll show you, and this is something, you know, we're obviously going to do in this workshop, is getting connected, and all you have to do is update your database credentials, like your host name and your database username. They're the two things you have to change, so that's typically, you know, an environment variable, it's a simple config change, so you can literally be up and running in kind of 30 seconds to root your data through polyscale, and the way that works is that we're focused on no code, as I said, we don't want you to have to start, you know, bringing in new client libraries, and again, it's not to say that that's not a good approach, it's just that we don't want to add another client library to your world, the world's busy enough as it is, and the way we do that is that polyscale is completely transparent to your current database clients, so if you're using, you know, prisma or you're using, you know, Mongoose or whatever it may be, polyscale is completely transparent, and the way that we do that is that polyscale actually sits there at kind of a TCP layer three, layer four, and it talks the native wire protocol of your database, so you're actually talking to a Postgres server or a MySQL server, and just to take a step back, I mean, what polyscale is, is it's a cache, so you have your database client connects into polyscale, and then polyscale connects into your origin database, and it's really, really simple to set up, which we'll show you, and then you get into sort of that central column, which is, okay, I've now got my database data flowing through polyscale, what do I cache, and that's, you know, again, if you've ever implemented a caching layer, is, can get complex really quickly, and there's the famous saying down there on the bottom of the bottom left around, you know, caching and naming things, and we definitely would agree with that statement, so really our focus is on making it effortless for a developer to have to think about what to cache, so if you're in an environment where you're sort of coming at this with regards to I've got five microservices, and I know exactly what I want to cache and for how long, then great, you know, you can go and configure those. The flip side of that is how do those change over time, so is there a more optimum TTL value based on, you know, cyclical, you know, time-based fluctuations, so you could say, for example, in an e-commerce world, maybe there's a spike at, you know, midday UTC where lots of people come online in their lunch hour, you know, so how would my caching behavior change through that period, or should it change, and then you get into much more complex systems whereby maybe you have 5,000 unique SQL queries flowing through the platform every day, you know, where do I start there, which ones should I cache, how long should I cache those for, and that's a really hard thing for a human to do, and that's where we bring in artificial intelligence and machine learning, and what Polyscale does is it interrogates and views every single SQL query that comes through the platform, and it will adjust the caching behavior based on what it's seeing, you know, what's the actual inbound behavior of that traffic, and it automatically sets how long that data should live for in the cache, and what that means is you can literally turn on Polyscale, as I've mentioned, update your config file, start sending your database traffic through there, and Polyscale will then start selectively choosing what to cache and accelerating your data, and it does that globally, so it does that in every point of presence, so that's a really, we see that as being incredibly helpful, so say I've got a Drupal system or, you know, something with more complex SQL queries, wordpress or whatever, or an e-commerce platform, you can switch this thing on, and it will start caching selectively, you know, your data. Now, the immediate question here is, okay, well, what about invalidation, and what about my writes, you know, what about my inserts, updates, and deletes, my manipulation queries, what happens to those, so Polyscale in real time inspects every query, and it works out, like, is this a select or a show, is it a read query, and if it's not, then it sends that on to the origin database, so your transactionality never changes of your database, we're not changing anything in that behavior, so all those inserts, updates, and deletes get sent through, and your, you know, your consistency stays the same, your origin database stays the same, and the other cool thing about this, if you sort of will go into this and demo this and have a place, this validation, so if Polyscale sees one of those manipulation queries, an insert, an update, or a delete, it will automatically invalidate that data from the cache in real time globally, so if we send, you know, update table X, set user name equal to foo, it will go and blow away that data from the cache globally automatically for you, so again, the next time the next read comes in, it will pull that from the origin and populate the cache, and you always get the real-time, the freshest data, so that's a big, we see that as a big piece of engineering that, you know, developers don't have to build, I don't have to worry about that sort of invalidation side of things, and then the AI is also very clever around it monitors for payload changes coming back from a database, so if we're seeing database changes going on, we adjust the caching time to live respectively as well, so if there's stuff going on on the database that we can't see, then, you know, we're quite clever around how the AI manages that as well, you know, the classic scenario is let's take something like a travel agency where they may be collecting data from numerous different inputs, numerous different data sources, so there may be stuff going on on the database that we can't see. Talking futures as well will also be having the ability to plug in change data capture streams into Poliscale if that's something that's, you know, important for your caching semantics. So, yeah, you know, full automation, if you're not, if you want to, I mean, just to be clear, you can also completely override the automation, you could globally switch it off and say, hey, I know what I want to set this to, and I can do that myself. Equally, you know, if you want to go down that path, we will recommend to you what we think or what the platform thinks you should set that caching value to. So that's a, you know, a nice feature that we're helping you, but you can go in and overwrite this stuff. It's not a, you know, it's not a complete black box that you don't have control over. And then finally down here, you know, one of the features we've got coming in the short term is what we're calling predictive warming. So this is classic personalization use case whereby I'm logging into a system and I want to, you know, load up, again, my cell phone provider, show me my bill or my usage for the month, or I'm logging into, you know, something like iTunes or whatever and show me my personalized view. So we can, you know, accelerate that loading in the background. So we're looking at clusterings of queries that typically run together and we can execute those and make sure the cache is warmed for that particular user, which is, which is really exciting. And then the final bit, which is sort of the crux of this talk really is like, how do we scale, you know, great, you're giving me a cache for my database, but how does that scale? And as I said before, we sort of, we have points of presence globally and we put those as, you know, as close as possible to the application tier wherever you're scaling to. So that moves the compute, the query compute, and it moves the data itself physically closer to the application tier. Another feature we've got coming very soon actually is, is connection pooling. So to be able to, if you consider, for example, I want to run functions at the edge, those are very short-lived as we've already talked about, and there may be thousands of those running concurrently. That's exactly the use case for connection pooling, whereby, let's say I've got a Postgres instance running, that's running out of, of Paris in France, and let's say I've got a Postgres instance running in France, and let's say I'm now using Polyscale to serve that globally. I'm also using my favorite, you know, function as a service provider, and we are using lots of, we're initiating lots of TCP connections. So for example, I know at the time of this presentation, cloudflare, their workers platform, they're about to introduce TCP support. So for example, lots of functions globally connecting back to Polyscale at that data tier, and Polyscale manages the pooling there. So you'll have a small number of long-lived connections going back to your origin database, and then a very, very high number of, you know, ephemeral short-lived connections hitting Polyscale. And then the other sort of big problem we see in scaling these data systems is like how to shard. You know, many databases have great features around sharding, but you've got to decide what data lives where, and that's not always an easy decision. So a use case that springs to mind is a large gaming company who do leaderboard management, and that's a constantly changing thing, and it's also a constantly changing thing globally. So this, you know, a leaderboard, for example, is not something, I mean, you can obviously have regional leaderboards, but a global leaderboard that's constantly changing with, you know, thousands of updates every minute going on, and people want that latest data. It's not good enough to have that, you know, distributed and not be accurate. So how do you shard that data? How do you, you know, do I store everything everywhere, or do I separate out those reads into a platform like Polyscale? And, you know, so we shard that data based on demand, and the difference is Polyscale is not a database. So you can scale terabytes of data to every Polyscale region incredibly cheaply and without performance degradation. So, you know, Polyscale can support tens of thousands of concurrent queries without showing any degradation at all. We're not hitting indexes. We're not, you know, doing all the complex things that we need from our database. We don't have to do that, so we can be very fast and consistently fast as well. And just to give you a sort of an idea, so we can, you know, if you have any database query that's cached, Polyscale will serve that in a less than a millisecond, a millisecond or less, at scale. And this is, you know, huge benefits, obviously, for, because what's actually happening is that you're splitting out your reads from your writes, which then gives your origin database more performance to manage those writes and Polyscale can offset the reads for you. So, yeah, and then I think that that covers everything nicely here on kind of, you know, how we think about the world. And I'll just pause. I've obviously talked a lot, but yeah, any questions, anything on people's minds you want to drop into the chat or unmute and introduce yourself, and we'll chat through it. Hi. Hi. Yes, how are you? Good. Nice to meet you. And you. Thanks for joining. Thank you. So, I have a question about how, I'm just basically trying to see how you would integrate Polyscale for, say, an enterprise with, say, the following objectives for that backend. How would you integrate Polyscale for handling large volumes of, when you need to handle large volumes of automated responses with handling data that needs to be sent to APIs that handle OTP verifications and notifications to customers, as well as channeling those messages to the right recipients. And lastly, the ability to create logs and automate report generation. Yeah. Okay. You touched on lots of good stuff there. So, and I can see there's a couple of good questions in the chat as well, which we'll come onto. So, yeah, I think, I mean, if I was to sort of try and address that really high level, I think we've talked about there is kind of some short form responses that change quite frequently. They're quite fresh. So responses to sort of chat and customer responses right through to kind of very large, potentially large payloads that you see with things like business intelligence and reporting and things of that nature. So I think there's two areas of that. So if I take the BI one first and, you know, I've done a lot of work in my history with things like Tableau and building huge reports and I've sat there and watched these things take 50 seconds to render because they're running all sorts of, you know, unoptimized database queries that are getting generated through the whatever tool of choice you're using. And, you know, of course, once that's being cached by Polyscale, again, we'll serve that in a millisecond or less, doesn't matter the size of the payload. You know, what we're actually doing is we're a disk based cache. So we're dropping it onto disk. We do have a L1, L2, but the core of it is a disk based cache. And so that if that payload can be very large, and it really doesn't matter to Polyscale to be able to serve that. So in that kind of BI use case, in that analytics use case, if you're using like a fat client like Tableau or whatever, the user just changes their host name to connect to Polyscale rather than their source database and nothing changes. And then you can decide, well, you know, as we'll go into in a moment when we get into the product, you can cache stuff either fully automatically, you can set individual rules per SQL query, or you can actually set rules on a per table basis. And that works quite well in the BI world where you can say, look, I know my products table, I'm going to cache that for 10 minutes, or I know that only updates once a day. So let's cache that for a few hours. So you can really boost performance very quickly in those sort of BI and reporting worlds. And they're the ones that typically do expensive queries, right, whether they're hitting a warehouse or, you know, whatever it may be. And then if I come back to sort of your first part of the statement, you're talking about, you know, sort of fast changing data that you're responding to customers or maybe chat messages or and, you know, those are really, again, if we see the the invalidations coming through Polyscale, if Polyscale can see those inserts, updates and deletes how quickly they're changing, it will just blow that data away for you. So you're always serving the latest stuff. Now, a great use case we've got at the moment we're working with a customer is similar to this is an online booking one. And in the online booking world, you have a lot of in this particular example, there's a there's a point in the day where everybody tries to book, there's an event where everything becomes available, and everyone tries to book at that specific time. And what you see is, you know, you would think caching doesn't work very well in that kind of world. But what's actually happening is that when a booking slot is gone, you see that invalidation to the cache. And then, you know, once that's recached within the next couple of milliseconds, you then get hits. And you can actually alleviate a huge amount of that traffic from this huge sort of stampede that occurs when it hits a database. So even in high right environments, because Polyscale is very fast at rehydrating the cache, and invalidating a cache, you can get significant benefits. And then the last part, you talked about sort of scaling api's and stuff, we see that a lot where, okay, you know, I don't want to sound facetious here, but I really love you know, the jam stack is incredible. I love that. But you've got to focus on how do I scale my api's in that situation. And that's a, you know, a simple use case is okay, I need to authenticate my api call. And that typically goes back to a database. And that's a classic one for Redis, right? Let's, let's cache everything in Redis so that we're not validating those, those, you know, those tokens every time somebody makes a call. And that's a great example for Polyscale. Just plug it in, no code to write, scale your api, you know, without actually having to worry about how that gets gets invalidated. So yeah, hopefully that answers your question. And yeah, we can chat more on those a bit later on. And just looking at, sorry, go ahead. Same. Thank you. Yeah, it answered a lot of my questions. Fantastic. Thank you. It's a great cache here. It's a quick cache. A great question here. What if there was a bug in the app and Polyscale cached the broker results? How do we handle this? Truncate the whole cache or invalidate my period? Yes, you've got a couple of options, right? So as I'll show you in a second, you can either go in and press the blow away the cache, you know, purge cache globally, which may or may not be a heavy handed approach. If that's something you realize you've done and just go and blow it away. The other option is you let it expire, it will get refreshed. The third option is you could actually send if you again, depending on the situation, you could just send an update query for that bit of data. And we blow just that bit of data away from the cache. Or thirdly, sorry, fourthly, you programmatically, you can call an invalidation of the whole cache if you want to as well. So there's various ways from UI to api to letting it time out to invalidate that bit of data. How are costs calculated? Yeah, we'll come on to that high level number of connections, concurrent connections, you just buy a plan. There's a free developer plan. And if you're as it is, it is or Ignis hit the website. Now look at the pricing and you'll see there's a free plan to get started. And you can scale up from there. And there's an egress cost for gigabytes transferred per month. Good. I'm just looking at one more question before we get into a demo because I can't wait to play with the demo. But I have some questions about the cache data. Who has access on the raw data in each node and the data stored encrypted? Yeah, good question. And the second question is the recommendation feature you make the analysis based on the queries or in the raw data? Yeah, good questions. So what just to give you some comfort around the data storage side of things. So two areas, you can either just come to poly scale and use our SaaS service, and we'll cache that data for you. Or you can actually deploy poly scale, large enterprises deploy poly scale into their own networks, just so they can host inside of their own networks. So if for compliance reasons, that may be essential. And what happens is the data, you know, those those sort of points of presence inside an enterprise, connect back to poly scales control plane, which is completely anonymized. So the cache management all happens centrally, but the hosting of the data and the data never leaves your network. The second point on that is to be really clear about what do we actually store. It's not like we're a read replica, we don't go and grab your database and replicate that somewhere. What we're actually storing is the results to queries. So if I said, you know, select star from products where name like Nike, I get a result set back. And that's what poly scale actually stores is that result set. So as far as, you know, the validity of the data and where that data, you know, being able to interrogate that data in kind of a malicious way, it's a very different proposition from maintaining a database, you know, a complete read replica of that data. Thirdly, yes, we can encrypt the data on disk, you can decide if you want to do that, you will pay another sort of millisecond penalty for doing that, but completely valid. If that's something you want to do. And then there's all sort of the networking options around how we secure with SSL and allow lists and all that good stuff that we can we can cover and is on our doc site as well. So I definitely urge you to dive in there. And we can do everything from VPC peering and endpoints through to complete dedicated poly scale. So you can come to us and say, Hey, I would like a dedicated poly scale, please. And we can deploy that for you very quickly. And then, yeah, we'll come on to the analysis stuff now. But just quick answer to that question is, we analyze based on every individual SQL query. And that's what we recommend on. And that's done in real time in a continuous manner. But yeah, let's show you a quick demo, if that's okay. Now, what we've got is a demo cycle playground poly scale.ai. And let's blow this up a bit. And this kind of has three steps to it. Now, we have a completely public MySQL database. That's a read only user, but be gentle with it. It's not a big instance. And, you know, what we can do is we can have an application server, which is this playground, it's running out of a US East region, and we got a database running out of the EU West, I believe that's in Paris. And if I click this button here, it will run just some random query for 20 seconds. And that's going direct, as you can see direct to that database. And this is kind of, this is outside of our VPC. It's a real legit web application running in, I think this runs in Heroku. It's nothing to do with with poly scales environment. And this is running. If we scroll down, it's running this SQL query as fast as possible sequentially. And it's just varying this department name. So if you want to log into that database and have a look around, you'll see we've got this employee schema that has a bunch of tables. This is a public open schema that's linked to down here, you can have a play. And we're just varying this department. And that's what you can see in these log files here, we're changing this department. And you can see that the average query took around 400 milliseconds for those two regions. Now, step two, we just literally update our host name, and database username, and we'll come on to how do I connect poly scale in a second, but that's literally all we do. And it will then automatically connect to the closest point of presence, because it resolves my SQL dot poly scale global to wherever the closest pop is. So if I connect poly scale, what you'll see is everything gets cached. And then everything, you know, these blips of things getting cached are being evicted. And then everything gets served in one to two milliseconds. And this measurement here is including the network latency between the execution, and actually returning that data back to this web app. So that's inclusive. And then what you can see here is like, you know, direct, we did 48 queries. And then through poly scale, we did 17,000 queries. So that's a cool help. Hopefully, that helps you sort of visualize like what we do with a single config change, no development, no running code, no deploying servers, you can just blow out your reads globally with massive performance gains. And that's Yeah, so have a play with a playground that's completely public. And what we do now is we'll flip into the product. And I'll actually show you kind of well, what's happening under the covers. And as a user, how do I how do I do this? How do I get on board? So pop back to the Yeah, let's let's dive in and have a look at the product. So yeah, if you want to sort of anyone wants to sign up and have a play and you know, play along at home, it's go for it. So completely free to sign up as I say, you can see the pricing here. And what we do is we have a basic developer account, you know, 10 concurrent connections, sign up for free. And if you do that, I'm just going to log in with my GitHub account. And then that will give us the the dashboard. And what you'll see is we have the concept of workspaces where you can invite team members, and you can associate multiple caches with that. And I'm going to open my default one. And what you'll see is you already have a demo cache bootstrapped and configured. So there's already one set up. And the cool thing about this, if you just a nice hack, if you click this run sample queries button, it will take you back to the playground. But this time, it loads your current dashboard into here. So all these stats and stuff will go back to your dashboard. So you can see them. So just a quick, you know, if you want to have a play, sign up for an account, click on that run queries one, and that will take you to a dedicated playground environment versus the shared one that we were just we were just playing with. But yeah, let's start from the beginning. So let's say I've got a database and I want to get connected with poly scale. I'm actually going to use our playground one, which is the RDS instance that we we've just been playing with. And if you want those credentials, they're always on the playground homepage. So they're always here if you just want to play with the database. And I'm going to click new cache. So the scenario is I've got a MySQL database in this case, and I want to get connected with poly scale to my web app. So I'll click new cache. And as you can see here, you know, you give the cache a name. We select what database type we were supporting here. So you can see, as of today, we support MySQL Maria and Postgres. Microsoft SQL Server is coming next. And we got a you know, the list goes on after that. So I'm going to paste in my my origin hostname. And that's running on 3306. I've got a couple of interesting options here, I can actually if I want to disable caching completely. Now, the reason for doing this is we have lots of people sign up and they say, Well, actually, I just want to put poly scale in kind of an observation mode. I want it to just look at my queries and surface what's actually happening in the database without caching anything right now. And that's a really nice option. So I'm going to leave that on for this case. And you can also set the default behavior of the cache. So what this is basically saying is like, when I see a new query, should I go ahead and cache that? Should I manage that and poly scale do its thing? Or do I want to manually just set that myself do nothing? And you can set in you know, as we talked about already, you can set configure custom rules if you want to. But yeah, let me show you sort of how the AI works and stuff. We'll leave this switched on. So once I've got that set up, the only thing you now need to do to integrate poly scale is to change the hostname and also change the username. Now, one caveat here, this is for my SQL, we overload the database username, and you have to pass in your cache ID. That's the only thing you need to do. In Postgres, it works slightly differently in that you pass your cache ID in as the application name parameter. And just to be clear on that, I'm just going to the doc site. And if you go down to get connected, you can see there's a how do we get connected with my SQL MariaDB, which is passing your database username and your cache ID separated by a hyphen. But if I'm in the Postgres world, I pass in an application name with my cache ID. So depending on which database you're using, you've got to pass in your cache ID in one of two ways. And this data is always here. If you're opening up your cache, you've got the settings tab here. Let's slow down, I guess, lots of busy activity going on. But you've always got your connection details here. They're always available. So you've got the host and the port and the user string. So yeah, the cool thing is to just update your client applications to use that typically a config change. And what I'll do now is I'll fire up a bit of code and just show you how we can do this. So I've got some code and say, you're welcome to do this as well. I've actually set up a quick Node Congress repo here. So if you want to get connected and have a play to your instance, or just watch the demo entirely up to you. And you can literally pick your form of choice, whether it's prisma or PG, or I've got a connects example here for my SQL. And let's just open this up and have a play and I'll show you how we get this configured. So what I've got here is that repo, super simple. And I've got my MySQL with connects example. But as I've hopefully you've, you know, everyone's understanding, it doesn't matter what Orm you're using or how you connect, you just got to change these config variables. So I set my host up as mysql.poliscale.global, which is what I've copied from here. My SQL for Poliscale is on port 3306. So if you're using a different port, be sure to set that. And then the important bit is the database username, I'm passing in that cache ID, which is the unique identifier of our cache here, along with a hyphen and then the actual database username. So let's run through that example. Let's say my real database username, in this case, I'm connecting to that, that demo database, the username is Poliscale. So that's my real database username. Now, what I need to do is just put a hyphen in there, copy my connection, my cache ID, and paste that in in front. And that's the only change I have to make is the host name, the port and the username. And as you can see, with you know, when we were setting up that cache, if you remember, we didn't ask for your username and password of your database, which is a nice security thing like Poliscale can't see your database username and password. Everything says to sell encrypted and just get sent through to the origin database. So, you know, if I'm connecting as usual, I'll put in my database password, which is playground. And my database here is the employees one. And just to be clear, again, I know I keep repeating myself, everything's here on the playground homepage, if you want to grab those credits. It's also in the read me of this little demo repo. So you can see here, we've got the just the demo RDS instance we've got running there. So yeah, if we connect, oh, sorry, I'm all over the place. If we we've got that set up, and that's kind of all we need to do. Now, what I'm going to do before we sort of get into anything more interesting here, let's just run a quick query. So I'm going to comment this out here. Let's grab a Let's grab a query. And I'm going to say, select count star from salary for the fun of that. And let's run that code. No, my SQL. And that will make a connection. Oh, select count star from tables in place. Oh, there we go. I've made a I made a nice typo there. What I'll do is put node mon on. Check that table exists. I think we've got employees. I'm pretty sure that exists. There we go. Great. So we ran a query. Fantastic. So if you go back now to the break, it's interesting, you'll see the observability tab. And observability will show us every single query that runs through the platform. So we can see here, that's our example come through. We can see we ran that once, it's in an auto caching mode. So it's, and poly scale is currently telling us that that's highly cacheable. Now, let's see something a bit more interesting. If I do, where ID equals one. Let's do that. Oh, we didn't have an ID equals one. We didn't have an ID because I think the ID type in there really should look at the schema before I start playing with it. But yeah, what I'm going to demonstrate here is actually just do just take this query here. This is a bit more interesting. So this says, select count star, average salary from salary. So if we run that once, what we'll do, actually, no, let's open this up. What I'm going to do is I'm going to run that query in a loop and run that 30 times. So let's see what happens when we run that. So I'm going to save that. It's going to connect and it's executing that you see 1.8 seconds because we initiated a new connection. Now, bear in mind, I'm on my home machine here. I'm in the Bay Area, the West Coast, San Francisco area. So let's see what happened there. So you can see that we made the connection. We got a query runtime, like 1.6 seconds, one second, 1.2, really varied. And then look what happened a little bit later. Suddenly, we dropped down to 36 milliseconds and 44 milliseconds. And that was poly scale jumping in and saying, right, this is something we're seeing multiple times. It's a very simplistic query. We can set a high time to live on this value and start caching that data. We'll see this in our analytics here. And a couple of things you'll also notice in here is we anonymize the SQL data that comes through here. So if I had a parameter in here that said, select credit card number from where name equals whatever, where credit card equals this name or ID, we would actually anonymize that completely and take that out of the query. So we never store any SQL. All the parameters are anonymized for PII. So you'll never see that in here, but hopefully there's enough in there you can identify the queries. Now, if, for example, I wanted to set a specific rule on this query and say, well, actually, I don't want poly scale to manage it. Let's overwrite that. I can come in here and I can actually set a rule on there and I can set that to manual and I can create a query. You can see here we've got a couple of options. I can actually create a rule at the template level and a template is effectively a similar SQL query, but where the parameters have changed. So if I said select star from users where ID equals one, select star from users where ID equals 10, it's effectively the same query, but it's semantically different and poly scale will classify that into a template. So you'll only ever see one row in here. So if you want to come in and apply a time to live specifically, I can do that and I could set that rule up in here. And you can see I hit the set recommended button and right now poly scale is recommending a 30 second time to live for that query that we're just looking with because it doesn't know anymore. It's just seen one sort of burst of that data that came through. The other option also, I can even set rules on specific tables. And again, this is a great use case for things like really simplistic BI use cases or even e-commerce use cases where I say, look, I want my table to be cached for 10 minutes and I know that's all I want to do. That's the other option you've got. So that's kind of the very high level and when this gets more interesting is when you start getting into more complex systems, you can drill down to this detail section. Actually, let me just log in as a different, get you a different data set. There'll be a bit more interesting with some data in there. Let's do that. And I'm going to load up this Drupal test site that we've been had running for a while. And there's actually not much activity on here, but it's a live Drupal site that we just plugged in and had a play with and it's taking a bit of time. That should be nice and fast. So we'll give that a test. There we can see. This is quite an interesting summary report where you can see the number of queries that you're running or have run in the last seven days, the actual execution time that's run, your database time, and then the actual savings, possible savings if everything is cached, what the efficiency is. Now, if we look at this data, I'm going to drop into this details section here. And what you get then is the full breakdown of all of the observability that's happening. So you can see, this is a good example where you can see these question marks in here where we've replaced the parameters. You see what tables have been accessed. Is this query a DQL, a data query language? Is it a read? Is it a show or a select versus a DML query, which is a manipulation, an insert, an update, or a delete? And just to be clear, out of the box, again, we strive to hide this complexity. We hide the manipulation queries. So what you're seeing here are just the cacheable queries. So I can come into this filter option and I can say, show me my cache versus uncached, but specifically, do I want just the DQLs? Do I just want the shows and the selects? And I can turn that off and I can see all the reads, the inserts, updates, and deletes as well. And you can see these broad categories across the top. Don't be too overwhelmed by the minutiae here, but I can look at my queries. How many hits and misses have I had? How many are distinct? So that concept of a query template where I may have 5,000 unique queries, the same query, different parameter, that's what you're looking at here. And the reason that's a decimal, by the way, is because we're in the 15-minute time frame. So we're sort of chopping these up. You can see here, this particular query is uncached. We've turned the cache off on this one. We can see our hit rates and so on and so forth. You can see the total execution times in seconds versus average execution times in minutes. And if we go to the public playground data here that we were just running, and we'll see some interesting stats here. Let's let this load up. So this is just for the last 15 minutes and the queries that we're running through the platform. And it's pretty slow. Yeah, and this is interesting. So this is the playground query that we run, that we talked about before. And you can see that department name there being anonymized. And we can see we ran 12,000 of those. And if you start looking then at the time saved, that actually saved just under 80 minutes of database execution time. That playground run that we've all been doing on the site where we ran 12,000 queries, that looks like just one run in the last 15 minutes. That actually saves almost 80 minutes of database execution time. The actual time and the nominal time. And then you can see here the breakdowns of the average execution time as well. So you can really go down into all the details of exactly what queries are happening. And as I said before, Polyscale will surface the ones that are highly cacheable versus the less cacheable ones. So yeah, hopefully that's useful. And just to wrap up here on the settings page, you can change your defaults about how the cache behaves. You can purge. So that's going back to a question we had earlier. I can initiate a global purge if I want to, for whatever reason. If I have set up some manual rules in my cache and I've sort of said, well, let's cache these few queries manually, or I'm running stuff automatically, I can actually go and delete those rules. So you can just kind of reset how you're managing the rules when they come in. And then finally, I can actually delete this cache if I want to just blow everything away and get rid of this. So yeah, that's a quick sort of tour of high level overview of Polyscale and how it works. And just a couple of use cases that we really focus on is kind of that regional one, which we talked a lot about. But the other one also is kind of if you just want to scale a database, it's overloaded. And we work with lots of customers like that who are focused on just scaling a single database. And that's read query performance is the other key part of this. So they're really the focus areas of what we work on. So again, I'll just pause there. That's pretty much all the material I kind of wanted to show. And yeah, I'd love any questions, any anything I haven't covered that you're interested in, or if there's anything you've seen that sparks interest, then yeah, definitely, definitely give me a shout. Hi, Nishant. Hi, sir. Hi. I want to ask like, it works with the only MySQL or this language like I work with mongodb, Mongoose language. So how do it work with that language? Yeah, not yet. Mongo is not supported today. So you can see we've got MySQL, Maria and Postgres SQL servers next and likely then MySQL. And what we're focusing on at the moment is really the sort of pure TCP based databases that are hard to scale. So that's really where our focus have been. And later this year, we'll be adding support for HTTP with graphql. And, you know, moving into things like Elastic Search and Mongo as well. Yes, sir. Like the main languages, the Elastic Search and the Mongo is the very easily easy to response like these languages. Right. Exactly. So yeah, thank you. So right now, just the three supported with, we're expecting Microsoft SQL Server, just because we've got huge demand for it. We're expecting that around March time. That's the current ETA. Hello. Hi, John. Is it Gene or John? It's John. John, nice to meet you. Nice to meet you. Well, congratulations on the product that you guys have developed. Like, it's amazing. And well, I work on a large scale product that we have distributed over five regions globally. We get in the best of weeks during the year up to 33 million hits. And well, when I first joined the project a couple of years ago, one of the first things that we did was move the infrastructure from, you know, on site to be fully managed on aws. And we're using Atlas and we are using what you call this on Rackspace, we're using SQL Server. So I'm really happy to hear that you are definitely looking into supporting a SQL Server. Yes. And I would like to echo that Mongo would be amazing for us to have as well. Because honestly, the way that we have architected our product is basically Mongo is for writes and then SQL Server for reporting. So that means that we really don't need caching for SQL as much as we need it for Mongo that we use it to, for example, we use the data from Mongo to print, well, to render landing pages. And those need to be rendered in 200 milliseconds or less. And we're not really hitting that mark. And having something like this, like we've gone through several iterations of using Redis and things like that would definitely improve our life significantly. So I'm really going to keep my eye out on poly scale for this. Like there are several of our team here looking at this and our heads have been exploded. That's great to hear. Great to hear. A large scale company looking into a solution like this if you guys implement Mongo and SQL Server. Definitely. So as I say, SQL Server is kind of imminent and work has begun on that. And then Mongo will be shortly behind it. So yeah, we hear the same from a lot of people. We've definitely heard that. And thanks for sharing your use cases there. I think certain places caching just makes so much sense where we need super low latency and half a second isn't good enough or five seconds isn't good enough. And it's great to hear that you're in that world where you do have those two different systems. You're in that polyglot world. And that's only going to, I guess, based on your business success, that whole scale, you need to get that to different regions and more people. And the data is increasing in size. So the problem's not going away. And I don't know if it's something you want to talk about, Jean, but the, you know, your experiences with Redis and, you know, obviously, Redis is a fantastic product. And did you find that that wasn't going to work or you just haven't attempted that project or did it just become too complex or kind of where did you get to down the Redis path? We're still in the middle of it. Actually, as I said, we've done a few iterations, like there's even an old iteration right now, which is breaking our heads because it has a little bit of a memory leak on Node. That's because it's a legacy server that should be sunset soon. But yeah, adding Redis is not as straightforward as people might think when it comes to scalability. For example, we are using aws with Fargate. And Fargate only allows you to expose port 80. So when you try to add Redis internally, because that's one of the things that we were trying to do, like put Redis right there in the Docker image, so that the application could contact it directly, you know, bare bones, and just have all of our applications be read replicas of the master. That was unsuccessful because of that, or it just added complexity. So those are the kinds of things that you will usually find that would be much better to just, you know, give it to somebody like your team and, you know, let AI take care of it. We would love something like that. Yeah, fantastic. That's great to hear. Thank you for sharing that. And I just want to take one question quickly in the chat. Are there any way to make manual overrides through code? Absolutely. So if you hit the docs, we've got a full api that you can get all the features are exposed through there. So you can, you can do whatever you want to do. So again, that kind of goes against our no code strategy. But yeah, the situations where you're definitely going to need to, or want to, you know, you know, better than the machine, and you may want to just invalidate at the right point. So, so yeah. Good. Anyone else for a question? Is it Mbeko? Yeah, I have a question. I'm sorry if I might have missed it. I heard you towards the end, you were talking about this being basically a service that you target when you have one big database. And that's one thing that I wanted to get clarity on. What, what, what happens when you have many different database say, you have hundreds of departments that some may have databases of their own. And others may have databases that they want to keep completely separate. Do you then need different accounts that are completely separate for each one of them? Or is it the integration that can be done? I think what you're describing here is Poliscale has a concept of workspaces. Show you that really quickly. I'll sign in as a different user. And a workspace is effectively an entity that can have one or more caches. So you could use a workspace for a department. You could use, you know, here I'm in my default workspace. And each workspace is associated with billing. So you can set up one or more caches in that workspace. And I could come in and create a brand new one that could be, you know, departments, whatever. And in there, I could create different caches. And then you can set permissions on your workspaces, you know, who you invite into. If I go into the access, you know, who do I invite into these workspaces and set their permissions. So you can set that to be a large enterprise or different departments or whatever you need it to be. Does that answer your question? Yeah, yeah, I think that addresses the question. So just one more thing with those workspaces. Are you then allowed to have different databases in it? Could you say have a database? Yeah, absolutely. So when you create a cache, yeah, when you create a cache, you each cache is a different database, right? It's independent. But you just select your database and you can have, you know, in my demo account, I was just in a minute ago, we had, you know, Postgres, MySQL, MariaDB, it doesn't matter. They're all in the same workspace. Okay, all right. Okay, thank you very much. Thank you. A couple more in the chat. Let's have a look. No Congress repo appears to be private. Oh, no, what a fail. Let's see if I can change that really quickly. Can I interrupt? Of course, yes, please do. Yes, I have one small question. I'm located, basically from India. Yeah. So it was very nice interacting with you on the polysail application. And I have a very small question. Is a polysail application work good with the large scale database? Any impact on performance while trying to operate on a small database? So I think if I understood your question, performance of small database versus large database, that's the area you're thinking about. Yeah, so I mean, with regards to the origin database, polysail is kind of agnostic. It doesn't matter. It's just a pass through cache. So whatever load your origin database is dealing with today, you know, it doesn't matter to polysail. So we're just either serving something from a cache or it lets it through to hit the origin database. So nothing changes with your origin database. You can run that on a $10 a month, you know, $30 a month RDS account right up to, you know, customers having 25 grand a month single instances. So the origin database is nothing to do with polysail other than kind of we're a pass through back to it, if that makes sense. Thank you. Great. Another question in the chat. Is there a student developer pack? No, nothing on the box kind of specific for students. Obviously, we do free accounts. We can do nonprofit accounts, definitely. But no, I think the platform is the same for everyone scales up for everyone. But yeah, let us know if there's something specific you were you had in mind and we'll look to accommodate. Okay. Yes, I do have one more question too. Yeah. Yeah, I just thought about this. I'm not quite sure if it's actually possible. What I'm getting is that you're basically trying to possibly reduce the amount of integrations that you would need to make calls to the database and what's on. So is it would it be possible then to just completely eliminate something like redis or would it need an integration at the same time? Yeah, I mean, we see use cases where people they're either completely remove redis. So, I mean, I don't want to talk about redis specifically, because I love the products. Great. But the the specifics of running caching at the application tier can be removed. So you're taking a step down, you're caching at that data tier, rather than actually in the application tier. And then just think about the luxury of not having to worry about that code overhead and the complexities there. That's really the benefit that we bring. I've just made the repo public, by the way. So feel free to have a play. But that's exactly right. We take away that complexity of having to write your own logic and maintain that over time. Okay, yeah. All right. I think I understand now. Great. So what's the name of the repo? It is a let me bring up the slide. Just hit the poly scale GitHub poly scale. And it's no Congress 2022, which is Yeah, that one there. I have to drop the shameless plug that we are hiring, and we would love to speak to anyone that's interesting, interested. At the moment, we're hiring for a developer advocate, full stack react and typescript engineer, and a C++ kind of proxy focused back end engineer. And you can read more about the company on the website. But we are, you know, we're a small company where we're 100% remote. So yeah, we'd love to speak to anyone that's thinking about, you know, if this looks interesting to you, and, you know, we're changing how, how databases are scaled. That's really the the mission we're on. So yeah, so say, have a look on the website and the career section there. And you can read more about the roles. Let's have a look. Any other questions? In the chat, let's have a look. Thanks for posting the link there. Yeah. And any other questions from any? Oh, sorry, is there any internal opening is also there? Sorry, Nishant, can you repeat that? In turn, like, you are the proper software engineer. Oh, in turn. Yeah. And not at the moment, and probably next year, as in later this year. So yeah, not at the moment, we're just hiring full time positions at the moment. But yeah, we'll definitely be looking to run an intern program, you know, within within the next six months or so. Okay, that's nice. And so you said those positions are remote first? That's right. So we're remote first company. We don't have offices, we are completely distributed. We have people across the globe in all sorts of great places. So yeah, we welcome that. Yeah, we are remote first company. Okay. All right. That'd be nice to look into. Great. Fantastic. Glad it was helpful. And yeah, okay, we'll, we'll wrap it up.
83 min
11 Feb, 2022

Watch more workshops on topic

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career