Will PgCache fit your workload?

Runs in your browser as WebAssembly · nothing is uploaded

Get your own report in about a minute

1 Export what your database actually runs
```
\copy (SELECT query, calls, total_exec_time FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 1000) TO 'workload.csv' WITH CSV HEADER
```
Writes workload.csv in your current directory. Drop that file in below.
```
SELECT query, calls, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 1000;
```
RDS, Aurora and Cloud SQL ship pg_stat_statements switched on. If the query errors, the extension isn't loaded yet - your DBA adds it to shared_preload_libraries, which needs a restart.
```
SELECT query, calls, total_exec_time
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 1000;
```
Run it, select the result grid, and copy. Paste the rows straight in below - the tab-separated copy your client produces is read as-is.
2 Paste it below, or drop the file

A plain .sql file of statements works too, and so does a PostgreSQL log. The analysis runs in this tab as WebAssembly: no account, no upload, no query text leaves your browser.
3 Press Analyze

You get the share of your database time PgCache would serve, which queries carry it, and what stays on your database.

No input yet

The answer

What holds it back

Biggest wins

Schema inferred from the queries · · the pgcache-fit command line gives the same report for larger traces

Rather not book a call?

Leave an email instead and we will help you read the numbers, get a trial running, or answer whatever the report raised. Your report does not come with it: the analysis stays in this tab, and all we get is your address.

What a fit report tells you

PgCache serves a query from its own copy of your data only when it can prove the answer is correct. The Fit Analyzer runs that same decision over a real trace of your workload and reports what it found, so you know the answer before you put anything in front of your database.

It reads a pg_stat_statements export, a PostgreSQL log, or a plain .sql file. The analysis runs in your browser as WebAssembly: no account, no upload, and no query text leaves the tab.

The four verdicts

Every statement lands in one of four buckets.

Cacheable. PgCache can serve this from the working set it keeps, tracking changes through PostgreSQL logical replication.
Forwarded to origin. PgCache passes the query straight through to your database. The report names the reason: a system catalog reference, a non-immutable function such as now(), an unsupported FROM clause.
Writes. These always go to your primary. PgCache follows them to keep cached rows in step.
Transaction and session commands. BEGIN, SET and similar. They pass through.

Why pg_stat_statements is the best input

A .sql file tells you which query shapes are cacheable. A pg_stat_statements export tells you which ones matter, because it carries call counts and total execution time alongside each shape.

The two answers are rarely the same. The sample workload on this page is 29% cacheable counted by statement, and 62% counted by database time, because the heavy reads are the cacheable ones. Only the second number predicts what you would actually offload. The report lets you switch between statements, calls and database time.

A PostgreSQL csvlog goes one step further: it preserves the order queries arrived in, which is what the hit-rate estimate needs.

What it will not tell you

The analyzer reasons about the SQL, not about your data or your security model. It cannot see Row-Level Security policies, which PgCache does not yet support, and it assumes a schema inferred from the queries themselves rather than a real one. Treat a strong result as a good reason to run a trial, not as a guarantee.

For traces too large for a browser tab, the pgcache-fit command line produces the same report.