---
title: "Mocking PostgreSQL the Easy Way: Simplifying Testing with Speedscale Proxymock | Speedscale"
description: "Record real PostgreSQL traffic with proxymock and replay it deterministically. No more local database setup, no more seeded test data."
canonical: "https://speedscale.com/blog/mocking-postgresql-the-easy-way-simplifying-testing-with-speedscale-proxymock/"
---

![Mocking PostgreSQL the Easy Way: Simplifying Testing with Speedscale Proxymock](https://speedscale.com/_astro/image1.9mE_tkAy_Z1qR6cQ.webp)

# Mocking PostgreSQL the Easy Way: Simplifying Testing with Speedscale Proxymock

Nov 24, 2025

[By Alan Mon](https://speedscale.com/blog/author/alan-mon/)

[Developer tools](https://speedscale.com/blog/category/developer-tools/) [DevOps](https://speedscale.com/blog/category/devops/) [Load testing](https://speedscale.com/blog/category/load-testing/)

* * *

Every developer who’s worked with PostgreSQL knows the pain: testing against a real database slows everything down.

You need the database running locally, loaded with the right data, and configured to match production as closely as possible. Every time you run a new test or build, you’re forced to repeat that setup migrate schemas, seed test data, and clean everything up again.

It’s time-consuming, brittle, and hard to scale across a team.

As Matt points out in [his video](https://youtu.be/hNbeoyiTmbs), database testing often becomes the **biggest bottleneck in modern development pipelines**. Whether you’re running integration tests on your laptop or spinning up ephemeral environments in CI/CD, managing a real PostgreSQL instance just to run basic CRUD tests wastes time and resources.

* * *

## Typical Solution

Developers usually take the “just clone it” approach.

They copy the PostgreSQL database, sanitize production data, spin up a Docker container or local instance, and load the dataset. It works, but it’s inefficient. Each time the schema changes or a test modifies data, the process needs to start over.

Here’s what the typical workflow looks like:

1.  Start PostgreSQL locally (often via Docker).
2.  Run migrations.
3.  Load sample or scrubbed production data.
4.  Run the tests.
5.  Reset the database and repeat.

It’s a familiar pattern — and a huge time sink.

This approach also doesn’t guarantee test stability. Two developers might run the same test with slightly different datasets and get different results. And in CI/CD pipelines, starting a PostgreSQL container and loading data for every job increases run times significantly.

In short, it’s slow, inconsistent, and expensive.

* * *

## Our Solution: Proxymock

With `proxymock`, you can replace all that overhead with a single, elegant solution.

Instead of running a local PostgreSQL instance, you can **record your real database interactions once** and then **mock them** during future runs.

Proxymock sits transparently between your application and PostgreSQL, recording every query, prepared statement, and result. Later, it replays those interactions — so your app behaves exactly as if it’s connected to a real database, but without PostgreSQL actually running.

You get the realism of live database responses without the complexity of maintaining one.

In practice, this means you can:

*   Run local or CI tests instantly without starting PostgreSQL.
*   Reproduce production-like results deterministically.
*   Avoid data drift between runs.
*   Simplify setup and teardown for developers and pipelines alike.

It’s the same power as having a lightweight, instant PostgreSQL clone that just works.

* * *

![ai generated image of 4 step process](https://speedscale.com/_astro/image1.9mE_tkAy_Z1qR6cQ.webp)

## Step 1: Record PostgreSQL Traffic

The first step is to record your app’s real interactions with PostgreSQL. Run this command in a dedicated terminal window:

```
proxymock record --reverse-proxy 15432=localhost:5432 --app-port 8080
```

This tells `proxymock` to:

*   Listen on port **15432** for PostgreSQL traffic.
*   Forward all requests to the real PostgreSQL instance at **5432**.
*   Capture every SQL query, result set, and timing metric in RRPair files (Request/Response Pairs).

Think of it as a “black box recorder” for your database — it records once so you can replay infinitely.

## Step 2: Configure Your Application

Now you’ll configure your application to route traffic through the proxy instead of directly to PostgreSQL.

In a new terminal window, run your app with modified environment variables:

```
PGUSER=<user> PGPORT=15432 go run main.go
```

Here, we’re telling the app to connect through port `15432`, where `proxymock` is listening. Your real PostgreSQL instance is still running at `5432`, but `proxymock` now intercepts every command.

This setup works for any PostgreSQL client — not just Go. Python, Node.js, Java, Ruby — all follow the same pattern.

## Step 3: Inspect What You Recorded

Once you’ve generated traffic (by running queries, tests, or your app), browse what `proxymock` captured in a local web UI:

```
proxymock web --in .
```

You’ll see all the SQL statements your app executed, along with the data returned by PostgreSQL.

Behind the scenes, each captured interaction is stored as JSON, even though PostgreSQL uses a binary wire protocol. This makes it easy to review or edit.

A typical RRPair might include:

*   The original SQL query or prepared statement.
*   The response rows and metadata.
*   Timing details like latency or execution duration.

You can even modify the JSON files manually to simulate different query results.

![example of proxymock used in production](https://speedscale.com/_astro/image2.ChLVbTz4_Z1pVSDV.webp)

## Step 4: Run the Mock Server

Now for the fun part. Once recording is done, you can stop your local PostgreSQL server (to free up port 5432) and start `proxymock` in mock mode:

```
proxymock mock
```

Your application can now connect to `localhost:5432` like usual, but `proxymock` will serve the recorded responses.

From the app’s perspective, nothing has changed — but in reality, it’s running entirely without a database.

## Step 5: Modify or Transform Responses

Sometimes, you’ll want to modify what your mock returns. Maybe you want to simulate an error, or test how your app handles empty results.

You can edit the JSON manually, or automate the process using Speedscale’s transformation system:

```
proxymock cloud push snapshot
proxymock cloud pull snapshot <id>
```

In the Speedscale UI, you can configure transformations — like changing returned values, introducing latency, or injecting errors — and then pull those updates back into your mock.

* * *

![snapshot of json path in cloud](https://speedscale.com/_astro/image3.BR9nRE-5_qV3Yf.webp)

More information about transforms can be found here: [https://docs.speedscale.com/guides/replay/mocks/edit-sig/](https://docs.speedscale.com/guides/replay/mocks/edit-sig/)

## Value

Let’s talk about what this means in real terms.

If it takes about **1 hour a day** for a developer to reset and reload their PostgreSQL database for tests, and your team has 8 engineers, that’s **8 hours wasted daily** — nearly **40 hours per week**.

With `proxymock`, recording a PostgreSQL session takes about five minutes, and then you can replay it endlessly.

That’s a **90% reduction** in setup time.

Multiply that across teams, CI runs, and staging environments, and you’re looking at hundreds of saved engineering hours each month — all while getting **more reliable, deterministic test results**.

You don’t just save time — you make testing faster, cleaner, and more consistent across environments.

![comparison of traditional postgres versus proxymock](https://speedscale.com/_astro/image4.CAXO1cF5_ZSoog6.webp)

* * *

## Conclusion

Database mocking doesn’t have to be complex or fragile. With `proxymock`, you can record once, replay infinitely, and eliminate one of the most persistent bottlenecks in testing.

If you’re ready to speed up your local and CI workflows:

*   🎥 [**Watch Matt’s video**](https://youtu.be/hNbeoyiTmbs) to see how database mocking transforms testing speed.
*   📚 [**Read the full Proxymock docs**](https://docs.speedscale.com/proxymock/guides/postgres/) for deeper details.
*   ⚡ [**Install Proxymock**](https://docs.speedscale.com/proxymock/getting-started/installation/) and try mocking your PostgreSQL database today.

Simplify your stack. Speed up your builds. Spend less time managing databases — and more time shipping great software.

## Table of Contents

## Stop writing API mocks by hand

proxymock records real traffic from your running app and replays it as mocks — HTTP, gRPC, Postgres, Kafka, and more. Install in 30 seconds, no account required.

[Install proxymock](https://docs.speedscale.com/proxymock/getting-started/installation/) [View the docs](https://docs.speedscale.com/proxymock/)