My app could read the database. pgAdmin couldn't. Both were pointing at "localhost:5432"

VidhiDixit2000 — Thu, 27 Aug 2026 08:04:06 +0000

I was running a FastAPI app in Docker with a PostgreSQL container next to it. The app worked. It wrote rows, it read them back, everything behaved.

The database itself, fastapi-db, was one I'd created inside the dockerised PostgreSQL — the container defined in my compose file. My app had created the products table in it and was happily writing rows.

Then I opened pgAdmin to look at that data directly, connected to localhost:5432, and found nothing. No fastapi-db. No products table. Just postgres, template0, template1 — the default databases of an empty install.

So my application was clearly talking to a database. pgAdmin was clearly talking to a database. They weren't the same database.

What I assumed first

My first thought was that pgAdmin wasn't refreshing, or that Docker wasn't persisting anything. Both wrong, and both cost me time.

The thing that actually settled it was running this in pgAdmin's query tool:

SELECT version();

It came back with:

PostgreSQL 18.4 on x86_64-windows

Windows. Not the Linux build that would be running inside a container. pgAdmin was connected to a PostgreSQL I'd installed on Windows months earlier and forgotten about — one that was running as a background service the whole time.

To confirm who owned the port:

netstat -ano | findstr :5432

That returns the PID holding the port, and it belonged to the Windows PostgreSQL service. It had claimed localhost:5432 at boot, long before Docker was involved.

The part I'd misunderstood

Here's what I hadn't grasped: my app and pgAdmin were reaching the database over two completely different routes.

Inside Docker Compose, containers reach each other by service name on the Docker network:

fastapi-container  ───►  postgres-db:5432

That never touches the host machine's ports at all. It's container-to-container, resolved by Docker's internal DNS. Which is why my app worked perfectly and gave me no hint anything was wrong.

pgAdmin runs on Windows, outside Docker. It can only reach the container through a published port — the host-side mapping in the compose file:

localhost:5432  ───►  (published port)  ───► container:5432

And localhost:5432 on my machine was already spoken for.

So one path was working fine and the other was quietly landing somewhere else entirely. Same port number in both places, two unrelated destinations.

The fix

Change the host side of the mapping so it doesn't collide:

ports:
  - "5433:5432"

The two numbers do different jobs, and this is the bit worth internalising. The left one is the port on your machine. The right one is the port inside the container. Postgres inside the container is still listening on 5432 and doesn't need to change — only the door on the outside moves.

Then a new pgAdmin connection to localhost:5433, and fastapi-db appeared immediately — the database I'd created inside the container, with the products table and the same rows my app had been writing all along.

My FastAPI config didn't change at all. It was still using postgres-db:5432, because it was never going through the host in the first place.

A smaller thing that had also confused me

pgAdmin's sidebar shows a tree called Servers, and I had two entries under it. I assumed that meant two PostgreSQL server processes.

It doesn't. In pgAdmin, a "Server" is a saved connection profile — a stored host and port. Two entries means "I know how to reach two PostgreSQL servers," the same way two contacts in your phone don't mean two phones.

That's why one of mine showed a red X. The server wasn't gone; pgAdmin just wasn't currently connected to it.

What I'd tell past me

If a containerised app can see its database and your GUI client can't, don't start by suspecting your app. Ask which database each one is actually reaching. Two commands answer it:

SELECT version();

netstat -ano | findstr :5432

The first tells you what you're connected to. The second tells you who owns the port.

And the general lesson, which took me longer than it should have: inside Docker and outside Docker are two different networks. Containers reach each other by service name and never touch your host's ports. Everything else — your GUI client, your browser, curl — can only get in through a published port, and that port is competing with every other thing installed on your machine.

Same number, different world.

The import that worked for months and broke on my first deploy

VidhiDixit2000 — Wed, 26 Aug 2026 19:40:00 +0000

Could not resolve "../styles/Randomfacts.css" from "src/pages/Randomfacts.tsx"
Error: Command "npm run build" exited with 1

This was my first deploy to Vercel, and my first thought was that I'd broken something in that commit.

I opened Randomfacts.tsx and found it importing Randomfacts.css — capital R. Then I checked the actual file sitting in src/styles/, and its name was randomfacts.css, lowercase.

So the import was wrong. Fine. But that raised a much more confusing question:

Why had npm run build never thrown this error on my machine?

The actual cause

Windows filesystems are case-insensitive. Ask for Randomfacts.css when the file is called randomfacts.css and Windows hands it over without comment. Both spellings resolve to the same file, so the mismatched import worked locally for months.

Vercel builds on Linux, which compares filenames byte for byte. There, R and r are genuinely different names — and the one my import asked for didn't exist.

Same code, same import, two different answers. The operating system answered, not the bundler.

The fix

I matched the import to the real filename. Then a Windows wrinkle worth knowing: a case-only rename won't be recorded by git, so if you rename the file instead of the import, it takes two steps.

git mv src/styles/randomfacts.css src/styles/temp.css
git mv src/styles/temp.css src/styles/Randomfacts.css

How to catch these before the build does

Use git ls-files rather than ls. It shows the name git actually recorded, which is what the build server checks out — your local filesystem will happily lie to you here.

git ls-files src/styles/

Compare that output against your imports. Any casing mismatch is a build failure waiting for your next deploy.

What I took from it

There's a whole class of bugs that only exist when your deploy environment differs from your development one. Case sensitivity is the most common. Path separators and missing environment variables are close behind. None of them are visible while you're only running things locally, and none have anything to do with your logic being wrong.

I'd been building this project on and off for months — adding functionality in bursts, brushing up on different concepts along the way — and only hit this on the first deploy. It would have taken ten seconds to spot if I'd deployed at the start.

That's the real lesson for me. Deploy early, even when the project isn't finished. Not for the URL, but because the deploy environment finds a category of bug that your machine structurally cannot.

DEV Community: VidhiDixit2000

My app could read the database. pgAdmin couldn't. Both were pointing at "localhost:5432"

The import that worked for months and broke on my first deploy