houdata.
Menu

Evaluate

Getting started with CacheDB

Understand CacheDB’s transparent proxy model, supported paths, and a safe way to begin a technical evaluation.

CacheDB is a database proxy for workloads where repeated reads, database load, and cache-consistency choices need to be made visible and controllable. It sits between an application and its database, uses Redis for eligible result reuse, and leaves the source database authoritative.

Start with the request path

  1. The application sends its normal database request to CacheDB.
  2. CacheDB parses the statement and applies the active cache policy.
  3. An eligible cache hit is returned from Redis without a database round trip.
  4. A miss continues to the source database; an eligible response can be stored for later reuse.
  5. Successful writes are observed and the policy can invalidate related reads.

This is not a claim of strong read-after-write consistency. Cache policy and invalidation are workload-specific operational decisions, which is why CacheDB starts an evaluation in transparent mode.

Begin in transparent mode

Transparent mode parses traffic and records its operational context without looking up or storing results. It is the right first step for a representative application path: teams can inspect query shape, rates, table relationships, errors, and cache-policy implications before result reuse is enabled.

Mode Result reuse What remains available
transparent Disabled Query parsing, metrics, metadata, and operational visibility.
full Enabled for eligible reads Visibility plus the active cache and invalidation policy.

Moving to full mode is a controlled change, not a consequence of installing a proxy.

Choose the intended path

CacheDB provides native transparent relay paths for PostgreSQL and MySQL. It also provides PostgreSQL-front-end translation paths for PostgreSQL, Oracle, SQL Server, and IBM DB2. The database name alone is not enough to choose a path: client protocol, SQL dialect, prepared statements, transaction behavior, driver dependencies, and network topology all matter.

For PostgreSQL and MySQL, the proxy keeps the existing native client protocol. Translation paths use a PostgreSQL client interface and require workload-level validation against the target database.

Read Compatibility & security before selecting a path for production.

What to bring to an evaluation

Start with one important application flow rather than an abstract database inventory. Identify the client protocol, database engine, approximate read and write mix, data-consistency constraints, current bottleneck, and the outcome you need to validate. Do not send credentials or production data by email.

CacheDB can then be evaluated with a controlled baseline, transparent traffic observation, a reviewed cache policy, and workload-specific success criteria.

Next step

Read Deploy CacheDB to review the operating model, or request a technical evaluation with the application path you want to assess.