PgCache is a smart read replica for PostgreSQL that caches the hot data driving most of your traffic. Stop paying to replicate cold data. Try it for free on a small workload, then scale as you grow. Change one connection string. Never serves stale data.
If you're using traditional read replicas to scale PostgreSQL, you may be paying to duplicate far more data than your workload actually needs. That means more always-on compute, more storage, more transfer cost, and more operational overhead. PgCache takes a simpler approach.
The Pareto Advantage
PgCache acts as a demand-driven proxy in front of PostgreSQL. It automatically caches the queries and data that are used most often, so you can get the benefits of a read replica without duplicating your full database footprint. The result is faster reads and lower infrastructure waste.
Drop-In Deployment
PgCache is a wire-compatible PostgreSQL proxy. Just update your connection string. No application code changes, no Redis layer, and no separate cache invalidation logic. Uncacheable queries pass through transparently to your origin database.
Always Fresh
PgCache uses PostgreSQL logical replication to keep cached data synchronized with the source database. Writes continue to go directly to your origin database, while reads are served from cache when possible. That means you can reduce stale-cache risk without adding complexity to your application.
Works With Your Existing Stack
PgCache works with PostgreSQL 16, 17, and 18, and supports any ORM or driver that speaks the PostgreSQL wire protocol. It handles parameterized queries, JOINs, aggregations, GROUP BY, DISTINCT, and window functions. If your app runs on Postgres, PgCache can fit into your existing stack.
Pricing That Scales With You
Start with a free small instance or 30-day free trial to test PgCache on a real workload before committing. After that, PgCache bills hourly per instance, the same way your read replica does. Run it 24/7 and it is a flat, forecastable line item: about $156 a month all-in for the recommended m6g.large. You are metered on instance hours, not queries, so the bill does not move when your traffic does.
Cache the 20%, Offload the 80%: Automatically identifies and caches hot query data using demand-driven logic. Stop brute-force scaling and paying to replicate 100% of your cold data.
Always Fresh, Never Stale: PostgreSQL Logical Replication (CDC) keeps cached data perfectly in sync in real time. No TTL guesses, no stale reads, no cache invalidation logic in your application.
Test for free on a small workload, then pay by the instance hour. No per-query charges and no surprise bills, because your traffic volume is not a billing dimension. Running at scale? Contact us for a private offer at aws-team@pgcache.com
AWS Marketplace now accepts line of credit payments through the PNC Vendor Finance program. This program is available to select AWS customers in the US, excluding NV, NC, ND, TN, & VT.
Try this product free for 30 days according to the free trial terms set by the vendor. Usage-based pricing is in effect for usage beyond the free trial terms. Your free trial gets automatically converted to a paid subscription when the trial ends, but may be canceled any time before that.
You pay by the hour based on the EC2 instance size you run PgCache on. Six instance options are available: t4g.small, m6g.medium, m6g.large, m6g.xlarge, m6g.2xlarge, and m6g.4xlarge. These are not feature tiers. They differ only in compute capacity, so pricing scales up as you pick a larger instance to match your workload. You choose the size that fits your read traffic. Billing is usage-based and hourly, with no per-query charges and no monthly software fee. Run it continuously for a predictable, forecastable cost.
Top-of-mind questions for buyers
What does the hourly instance charge actually pay for, and what runs on it?
You pay for one running instance that acts as a caching proxy between your application and your PostgreSQL database. Each instance size maps to a set amount of compute. The proxy caches the hot data your traffic touches, so a larger instance handles more read traffic and cached working set.
Am I charged when the instance is stopped, and are there extra per-query fees?
Billing meters running instance-hours, so a stopped instance stops accruing software charges. There are no per-query charges and no monthly software fee. Underlying AWS storage may still bill separately while an instance is stopped. Run it continuously for a flat, forecastable line item.
How do I pick an instance size, and what happens if my read traffic grows?
Choose the instance size that matches your read workload; the six options differ only in compute capacity, not features. If traffic grows, you switch to a larger instance and your hourly rate follows that size. The change is manual — you select the new size when you deploy.
Tell us how we can improve this page, or report an issue with this product.
Give us feedbackReport a problem with this product or seller
Legal
Vendor terms and conditions
Upon subscribing to this product, you must acknowledge and agree to the terms and conditions outlined in the vendor's End User License Agreement (EULA).
Content disclaimer
Vendors are responsible for their product descriptions and other product content. AWS does not warrant that vendors' product descriptions or other product content are accurate, complete, reliable, current, or error-free.
An AMI is a virtual image that provides the information required to launch an instance. Amazon EC2 (Elastic Compute Cloud) instances are virtual servers on which you can run your applications and workloads, offering varying combinations of CPU, memory, storage, and networking resources. You can launch as many instances from as many different AMIs as you need.
Version release notes
PgCache 0.6.4 - 2026-09-18
Bug Fixes
Memory growth with many connections - every connection kept its own parsed copy of the cacheability analysis for each distinct SQL text it had seen. Analyses are now interned once per process and shared across connections.
Unbounded histogram samples when /metrics is never scraped - latency histogram samples were only drained on a /metrics render, so a process that was never scraped retained every sample it had recorded. Samples are now drained once a second regardless of scraping.
CDC apply no longer waits behind a population merge - a population's staging->cache merge ran as one statement per relation on the writer thread, so no CDC change applied until it finished. The merge now drains staging in bounded chunks with CDC applied between them.
Abandoned population staging is emptied in chunks - when a population is superseded, invalidated, evicted, aborted, or fails, its staging tables used to be emptied with one DELETE on the writer, stalling CDC apply for seconds on large populations. They are now drained in the same bounded chunks as a merge, with CDC applied between them.
Eviction no longer strands a query mid-population - under a query-count cap, a pinned or CLOCK-referenced query whose population was still in flight could have its generation bumped by the eviction tick, abandoning the population with nothing to finish or readmit it, so it stayed Loading forever. Such candidates are now skipped for the round and bumped once Ready.
Dual-stack admin listener - the admin HTTP server bound to 0.0.0.0 is now reachable over IPv6 loopback too, so a container healthcheck against localhost:9090 works on images whose /etc/hosts resolves localhost to ::1 first. The bound admin address is logged at startup.
Docker image healthcheck - the image now declares a HEALTHCHECK on /healthz; the documented compose examples used curl, which the image does not ship.
Observability
pgcache.connections.cacheability_entries (gauge) - interned cacheability analyses currently referenced by live connections; bounded by distinct SQL texts in use, not by connection count.
pgcache.cache.merge.chunks_total (counter) and pgcache.cache.merge.chunk_seconds (histogram) - merge chunks applied and their wall time, the longest a CDC frame waits behind an in-progress merge.
pgcache.cdc.keepalive_marks_coalesced (counter) - a run of consecutive replication keepalives queued for the writer is now handled as one at its highest LSN, so a keepalive burst from a busy origin cluster costs the writer one iteration instead of one each.
Additional details
Usage instructions
PgCache AMI Usage
PgCache is a transparent caching proxy for PostgreSQL. This AMI includes PgCache and an embedded PostgreSQL 18 cache database, managed as systemd services. On first boot, a bootstrap script fetches your database credentials from AWS SSM Parameter Store and starts the proxy.
Prerequisites
Origin PostgreSQL database with wal_level = logical enabled
Database user with REPLICATION role attribute or superuser
IAM role attached to the instance with ssm:GetParameter permission
AWS Support is a one-on-one, fast-response support channel that is staffed 24x7x365 with experienced and technical support engineers. The service helps customers of all sizes and technical abilities to successfully utilize the products and features provided by Amazon Web Services.
TurboGate with MySQL is a complete automatic setup of your database and middletier proxy layer. It helps your business to use databases in a reliable and performant fassion. It also helps to set up your database environment in a fully automatic fassion with 1-click deployment.
An AI-powered PostgreSQL monitoring and management platform that combines real-time metrics, proactive anomaly detection, and an agentic AI assistant to help teams diagnose and resolve issues faster.
SmartAMI SQLSplitter for Aurora powered by MariaDB MaxScale is a MySQL / MariaDB proxy server that forwards all write operations to master instances and all read queries to slave instances.
TurboGate with MariaDB is a complete automatic setup of your database and middletier proxy layer. It helps your business to use databases in a reliable and performant fassion. It also helps to set up your database environment in a fully automatic fassion with 1-click deployment.
Be the first to review this product. We've partnered with PeerSpot to gather customer feedback. You can share your experience by writing or recording a review, or scheduling a call with a PeerSpot analyst.