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, 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 PolySkele does is it, it interrogates and views every single SQL query 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 that data should live for in the cache. And what that means is you can literally turn on PolySkele, as I've mentioned, update your config file, start sending your database traffic through there, and PolySkele 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 ecommerce 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 rights? 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 show? Is it a re-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 consistency stays the same. Your origin database stays the same.
And the other cool thing about this, if you sort of, and we'll go into this and demo this, and have a place. This... Invalidation. 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 username 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 piece, we see that as a big piece of engineering that, 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're just the caching time to live respectively as well. So if there's stuff going on, on the database that we can't see, then we're quite clever around how the AI manages that as well. 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, we'll also be having the ability to plug in, change data capture streams into poly scale, if that's something that's important for your caching semantics. So yeah, full automation. If you're not, if you wanna, I mean just to be clear, you can also completely override the automation. You can globally switch it off and say, hey, I know what I wanna set this to. And I can do that myself. You know, if you wanna 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 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, 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 really exciting. And then the final bit, which is sort of the crux of this talk, really is like, how do we scale? Yeah, 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 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 connection pooling. So to be able to, if you consider, for example, I wanna 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 Paris in France, and let's say I'm now using Polyscale to serve that globally, I'm also using my favorite function as a service provider, and we are using lots of, we're initiating lots of TCP connections.