How to Stop Docker (PostgreSQL) from Freezing Your Older PC (Linux & Windows)

Cover photo by Source.

Hello — if you suffer from a slow PC for full-stack web development due to it being an older machine, this one is for you.

This article helps specifically with making database reads and writes more responsive in dev environments — Docker-contained ones, to be exact — and here is how to do it.

My setup: Dell Latitude E6540, Core i7-4610M (dual-core physical, quad-core logical), 8GB RAM DDR3L, and a 7200RPM HDD.

I forced Docker to read and write its heavy development files directly inside my system's RAM instead of on my disk. Docker has a built-in feature called tmpfs mounts designed exactly for this purpose, and I used it to create a temporary virtual drive in RAM for a container.

The strategy I explored is called Write-Ahead Log (WAL) tuning in database engineering, where delayed commits or asynchronous flushing are used for data reads and writes.

The premise: instead of my slow mechanical hard drive grinding every single time a user (me, in my local dev environment) clicks "like" or logs in, my database holds everything in the comparatively ultra-fast RAM and writes the data to disk in one clean batch every few seconds.

With this you get close to RAM speed, but your data is still permanently saved on an older PC.

Here is how you can set this up easily using PostgreSQL in Docker.

The Implementation: docker-compose.yml

Best part is you don't need special programming scripts to do this — you just tell PostgreSQL to do this automatically by modifying its internal engine settings directly inside your docker-compose.yml file.

version: '3.8'
services:
  database:
    image: postgres:15
    environment:
      POSTGRES_USER: armstrong
      POSTGRES_PASSWORD: mypassword
      POSTGRES_DB: blog_db
    ports:
      - "5432:5432"

    # PERMANENT STORAGE: Where the batches are eventually saved
    volumes:
      - postgres_data:/var/lib/postgresql/data

    # THE SPEED HACK: Force PostgreSQL to hold writes in RAM and batch them
    command: >
      postgres
      -c synchronous_commit=off
      -c commit_delay=100000
      -c commit_siblings=5
      -c shared_buffers=256MB
volumes:
  postgres_data:

How It Works Under the Hood

• synchronous_commit=off: Normally, when your Next.js app saves a session or a blog post, PostgreSQL blocks your app until the mechanical hard drive physically moves its arm and writes the file. This setting tells the database: "Save it to RAM instantly and tell Next.js it's done. Write it to the actual disk later in the background."
• commit_delay=100000: This sets a delay timer in microseconds (100,000 microseconds), forcing the database to wait and bunch multiple save requests together into a single, efficient disk-write batch rather than doing them one by one.
• shared_buffers=256MB: This dedicates 256 megabytes of your system RAM as a dedicated cache pool inside the container where active data tables sit waiting to be flushed.

The One Catch: The "Power Outage" Risk

Because the database is lying to your application and keeping data in RAM temporarily, there is a minor trade-off: if your laptop battery dies or Linux crashes at the exact millisecond you are saving something, you might lose the last 1–2 seconds of data.

For local development on something like a personal blog, this risk is completely irrelevant. Losing a single test comment, or having to re-log in after a rare system crash, is worth having a completely smooth, lag-free coding experience.