Running PostgreSQL on Windows feels deceptively simple for anyone with a Windows laptop that just wants a local database to test or demo on.  Just a few clicks and I’ve installed it, started the service, open psql and I’m up and running.
Except… not quite.
Because if you’ve ever seen this message:

Console code page set to 1252 for psql compatibility

You’ve stepped into one of the more subtle, frustrating challenges of running PostgreSQL on Windows. So, let’s talk about why this happens, what it is and why it matters more than you might think…

PostgreSQL Is UTF-8 and Windows Is Not

For most, if not all database professionals, UTF-8 is immediately understood.  It’s a character encoding standard that represents text as bytes so computers can store and transmit it.  Where computers store data as bytes, text must be converted into numbers.  Early systems used ASCII, which supported 128 characters and covered basic English letters, numbers and punctuation.  ASCII worked, until the rest of the world showed up.  It wasn’t able to handle:

• Accented characters
• Non-Latin alphabets
• Asian languages
• Emoji
• Mathematical symbols.

Due to this, different regions invented different encodings, (Windows-1252, ISO-8859, etc.) and that created a bit of chaos.  The same byte sequence could mean different characters depending on the system.  Then Unicode came onto the scene.

Unicode

Unicode is a universal character set that’s backward compatible with ASCII and can represent every Unicode character.  It assigns every character in every language a unique number, i.e. a code point.  Most European characters use 2 bytes, while Asian characters commonly use 3 bytes and Emojis use 4 bytes.  The allowed UTF-8 to become dominant very quickly as it doesn’t break ASCII and works everywhere.  An estimates says over 95% of the web uses UTF-8 today.
For PostgreSQL, the database platform defaults to UTF-8 and ensure support of modern applications that expect UTF-8. 

It’s almost unheard of to have data in a database that doesn’t require Unicode.
At the same time in Windows console? It’s living in 1998.
By default, Windows uses a legacy code page, most likely 1252 (Western European Windows).

That means:

• Special characters may render incorrectly
• Unicode characters may fail to insert correctly
• Output may appear corrupted
• Scripts may behave inconsistently

When psql starts, it often forces the console to:

Console code page set to 1252 for psql compatibility

That message is telling you:

“We’re downgrading your console encoding to something Windows understands.”

And that’s where things start breaking and did break as I built out my pipelines and workflows with my local PostgreSQL databases.

The Real Symptoms

This usually shows up in subtle ways:

• Smart quotes become garbage.
• International names don’t round-trip correctly.
• JSON containing Unicode characters fails validation.
• PowerShell scripts behave differently than expected.
• Migration files containing Unicode blow up.

Even worse? The error messages returned could be convoluted and not pertaining to the original failure.
You insert data and then regret it immediately upon querying it in psql.
Now you’re debugging “Postgres encoding issues” that aren’t Postgres issues at all.  It’s often more complicated that first suspected, too.
There are three layers at play:

1. Database encoding (usually UTF8)
2. Client encoding (SHOW client_encoding;)
3. Windows console code page

On Windows, the console code page dictates how characters are interpreted and rendered. If your console is using 1252, but your database is UTF8, you’re creating a mismatch between what PostgreSQL expects and what your terminal can handle.
PostgreSQL isn’t broken, it’s just that Windows is speaking a different language.

Forcing UTF-8

The fix is straightforward, but the levels it needs to be addressed is rarely documented clearly.
Before launching psql, set your console to UTF-8:

chcp 65001

65001 is UTF-8.

If you’re using PowerShell, you may also want:

$OutputEncoding = [Console]::OutputEncoding = [System.Text.UTF8Encoding]::new()

Then launch psql and then run:

SHOW client_encoding;

You want to see:

UTF8

And most importantly your Unicode characters will behave correctly.

The PowerShell with PostgreSQL Fix

If you’re automating PostgreSQL (Flyway, scripts, CI pipelines, AI-based SQL review tools, then you know the drill and encoding mismatches become even more painful.
You may see:

• Migration files failing validation
• JSON output mis formatted
• AI review pipelines choking on non-ASCII characters
• Environment variables not persisting correctly

And the root cause? The console was still using 1252 and kicking your butt.
When you see:

Console code page set to 1252 for psql compatibility

That’s your signal to take control of encoding before things get weird.


I had to ensure when I performed Flyway migrations that I was encoding correctly as well.  It’s just a small change, but it was essential to make sure there wasn’t any incompatibility.

flyway `

 "-configFiles=$($global:FLYWAY_CONF)" `

 "-url=jdbc:postgresql://$($global:PG_HOST):$($global:PG_PORT)/$($global:PG_DEMO_DB)?charSet=UTF8" `

 "-locations=filesystem:$($global:SQL_MIGRATIONS_DIR)" `

 Migrate

Why This Matters

Ten years ago, this wasn’t as visible.
Now we have:

• Multilingual applications
• AI-generated SQL
• JSON everywhere
• Emoji in product names
• Distributed teams across the globe

UTF-8 isn’t optional anymore.

I’m gonna say this and may offend a few, but it’s important to remember this is how it’s running, not an insult to Windows.  It’s about a mismatch.  I feel the same way about running Oracle on Windows.  It’s not a Windows problem but an Oracle support of Windows.  So, when running PostgreSQL in a non-UTF-8 console, you must remember that it’s like running a modern data platform through a fax machine.  A Windows PC is not a server, but when in Rome, become Roman.

A Better Long-Term Approach

If you run PostgreSQL frequently on Windows:

• Set your terminal profile default to UTF-8.
• Use Windows Terminal instead of legacy cmd.
• Configure PowerShell to default to UTF-8.
• Validate encoding in your CI pipeline.
• Explicitly check client encoding.

You can even bake this into your scripts: