For anyone using Fly’s postgres, I see Polyscale now support Fly
They provide a database query cache. By routing your connection via them, they can cache the response. That avoids needing an additional cache, which adds complexity (purging a cache traditionally being one of the hardest problems). Your app can stay exactly the same but get an instant boost by just changing the connection string:
Hey @greg - member of the PolyScale team here. Thanks for the post. Were pretty excited also by the possibilities of using Fly with external database providers which opens up a) the scope of viable databases (e.g. MS SQL Server), b) the range of database providers and c) users to move their app tier to Fly, without worrying about migrating their database if they choose not to.
That latter use case is where we are seeing customer interest.
We can roll out PolyScale to any Fly locations easily so feel free to reach out if there are any questions. Our team is also on Discord: https://community.polyscale.ai/
I found you last year looking for an elusive HTTP API Only Planetscale wrote an interesting blog post. To summarise their conclusion: “An HTTP API is actually really good . In most tests, any version of HTTP was superior compared to the binary MySQL protocol.”.
Does anyone have an example config to make polyscale work?
We are deployed to Fly, and using Neon with this config: Guide on connecting via Ecto - Framework Integrations - Neon
I am struggling with connecting to PolyScale.
The connection string with the appname does not seem to work at all.
I created a db user with the app name, but that has ssl issues with the config I put above.