We're building PolyScale[1] to address this problem. PolyScale is a serverless edge cache for databases so you can easily distribute your reads.
We are opening up early access to our connection pooling features in the next couple of weeks which allows FaaS platforms like Netlify, Cloudflare etc to create large numbers of ephemeral connections, without impacting your origin database, as well as reducing connection latency significantly.
I was looking at the polyscale docs and found following
PolyScale evaluates each SQL query in real-time and when it detects a DML query i.e. a SQL INSERT, UPDATE or DELETE, it extracts the associated tables for the query. Then, all data for the table(s) in question are purged from the cache, for every region globally.
Isn't clearing cache for entire tables for a all DMLs which may be changing one record too intensive and how does this affect performance of cache when there are multiple DML queries being run every minute?
Also can you please give the docs link to connection pooling feature
That’s right. Currently the auto invalidation is somewhat of a blunt instrument in that it will blow away all cache data related to the table(s) as default. That approach favors consistency over performance, but is also a natural fit to some query traffic patterns. You can also switch it off if you so desire. The next iteration that is imminent for release can be much more surgical, invalidating based on more of the query details.
Connection pooling docs are coming soon as part of the feature early access launch. Feel free to drop me an email and I can let you know when its released. Im ben at our domain.
We are opening up early access to our connection pooling features in the next couple of weeks which allows FaaS platforms like Netlify, Cloudflare etc to create large numbers of ephemeral connections, without impacting your origin database, as well as reducing connection latency significantly.
[1] https://www.polyscale.ai/