Plug & play caching
Add policy-controlled caching on the existing database path without rewriting application queries.
Explore this use caseCacheDB by houdata.
A performance layer for database workloads you cannot casually rewrite.
CacheDB is a transparent database proxy that observes repeated reads, reuses results where policy permits, and makes cache behavior visible to the operators responsible for the system.
The operating model
Preserve the system of record. Add a controlled fast path.
CacheDB sits between the application and the database. It preserves the client protocol, uses a distributed cache for eligible results, and routes every miss back to the source of truth. Multiple proxy instances can sit behind a load balancer while sharing a Redis Community, Valkey or Redis Enterprise cache.
Use cases
What teams use CacheDB for.
Explore three ways to apply caching and query visibility to an existing database workload.
Database observability
Investigate query traffic and share operational signals with DBA and monitoring teams.
Explore this use caseDatabase offloading
Serve eligible repeated reads from the shared cache, with potential to reduce primary database costs.
Explore this use caseCapabilities
Control performance without hiding the trade-offs.
Each capability is intended to be inspected against your database protocol, identity model, traffic pattern, and deployment boundary.
Five native database proxies
PostgreSQL, MySQL, SQL Server, IBM Db2 and Oracle proxies speak each database’s own wire protocol on both sides.
Transparent operating mode
All proxies can observe traffic with result caching disabled, then enable cache behavior only where workload and policy support it.
Distributed query cache
Reuse eligible reads under explicit policy with Redis Community, Valkey or Redis Enterprise as the shared cache for proxy instances.
Traffic-aware scripts and hooks
Review scripts that prepare SQL, decide cache eligibility and TTL, bypass reuse, or invalidate results after writes. Validate changes against real traffic before rollout.
Query investigation
Explore executions by client, backend and cache latency, hits and misses, and the writes that invalidate cached reads in the console.
Shared-nothing proxies
Balance connections across multiple proxy instances for high availability. Each proxy keeps no shared local state; the cache is external.
Monitoring integrations
Use console alerts with SMTP or HTTPS webhooks, export operational metrics to Prometheus for Grafana, and enable OIDC single sign-on for console access.
TLS on database paths
Terminate TLS from clients and establish a separate verified TLS connection to each database; plaintext requires explicit configuration.
Offline operation
Deploy in constrained environments with locally verified licensing and no control-plane dependency.
Compatibility
Five native proxies for the databases you operate.
Every proxy speaks the database’s own wire protocol. Applications keep their existing database driver and SQL while changing the connection address.
| Database | Client protocol | Proxy | Transport |
|---|---|---|---|
| PostgreSQL | PostgreSQL | Native proxy | TLS 1.2+ on both legs |
| MySQL | MySQL | Native proxy | TLS 1.2+ on both legs |
| SQL Server | TDS | Native proxy | TDS TLS, including strict TDS 8.0 |
| IBM Db2 | DRDA | Native proxy | TLS 1.2+ on both legs |
| Oracle | TNS/TTC | Native proxy | TCPS on both legs |
Built for DBAs and monitoring teams
Follow a query from workload signal to cache decision.
Start in transparent mode to see frequency and backend latency. In the console, inspect a query's executions by client and, when caching is enabled, compare hits, misses, cache latency and invalidations over time.
Use that evidence to review a cache rule and check its effect. Console alerts surface operational conditions; Prometheus exports fleet and cache metrics for dashboards in Grafana.
Explore console operations and integrations
Designed with boundaries
Performance needs a deployment model, not just a cache.
Native database paths support TLS between the application and proxy and between the proxy and database. Cache connections do not support transport TLS, so protect them with a trusted network or network encryption layer. The web console is designed to sit behind a TLS-terminating reverse proxy or WAF.
Cache identity matters too: use separate cache namespaces for database identities with different data permissions.
Read the security boundariesTechnical conversation
Evaluate CacheDB against your workload.
Start with the database, client protocol, workload shape, and performance constraint you are actually responsible for.