2 posts tagged with "caching"

App Hosting runs your container next to your data and gives it a URL at https://{name}.foundrydb.com. That is enough to ship, but production wants more in front of the origin: your own domain, a real certificate that renews itself, a cache so repeat requests never touch your container, a rate limit so one client cannot drown the rest, and a first line of defense against the obvious injection attempts. Until now each of those was something you bolted on yourself.

FoundryDB now runs that layer for you. The edge gateway is a managed HTTP front end that sits between the public internet and your app's origin. You turn on the pieces you want through one settings call, point a domain at us, and the platform handles certificates, caching, limits, inspection, and the analytics that tell you what is happening.

Most applications hit a performance wall that has nothing to do with their code. The database query that takes 50ms works fine until you are serving 10,000 requests per minute and your connection pool is saturated. Adding an in-memory caching layer drops that response time to under a millisecond and takes the read load off your primary database.

Valkey is the open-source, Redis-compatible in-memory data store that the community rallied behind after Redis changed its license in 2024. It is wire-compatible with Redis, which means your existing Redis clients, libraries, and tooling work without modification. No license concerns, no vendor lock-in, and active development under the Linux Foundation.

This guide walks through provisioning a managed Valkey instance on FoundryDB and implementing common caching patterns in Python, Node.js, and Go.