Prueba tu SQL contra un Postgres real, sin levantar servidoresTest your SQL against a real Postgres, without running a server
Los dobles de prueba no entienden SQL. Un Postgres compilado a WebAssembly sí, y corre en memoria.
Test doubles do not understand SQL. A Postgres compiled to WebAssembly does, and it runs in memory.
Durante meses nuestras pruebas de base de datos pasaban en verde y aun así un despliegue podía romper una consulta. La razón era simple: el doble que usábamos en las pruebas devolvía filas inventadas. No parseaba el SQL, no conocía las columnas y no sabía de tipos. Una columna mal escrita pasaba sin problema.
Postgres de verdad, en memoria
PGlite es PostgreSQL compilado a WebAssembly. Se instala como un paquete de Node, corre en memoria y no necesita Docker ni red. Es la única opción sin servidor que resuelve nombres de columna, tipos y operadores igual que en producción.
- Aplicamos todas las migraciones en orden, con el mismo separador de sentencias que usa el repositorio.
- Interceptamos el driver de la base de datos y mandamos cada consulta a PGlite, con los mismos parámetros que llegarían a producción.
- Corremos los manejadores reales, no copias simplificadas.
Lo que encontró la primera vez
El chequeo obligatorio antes de cada despliegue tenía una falla escondida: las sentencias que terminan en un SELECT escalar siempre devuelven una fila, y el script esperaba cero. El doble de pruebas contestaba cero y tapaba el problema. Contra un Postgres real apareció en el primer intento.
Si tu doble de prueba no reproduce la mecánica real, no está probando nada. Solo está confirmando lo que ya creías.
Hoy ninguna migración ni consulta nueva llega a producción sin pasar antes por un Postgres real en memoria.
For months our database tests passed and a deploy could still break a query. The reason was simple: the test double returned made-up rows. It did not parse SQL, did not know the columns and knew nothing about types. A misspelled column went straight through.
Real Postgres, in memory
PGlite is PostgreSQL compiled to WebAssembly. It installs as a Node package, runs in memory and needs no Docker or network. It is the only serverless option that resolves column names, types and operators exactly like production.
- We apply every migration in order, with the same statement splitter the repository uses.
- We intercept the database driver and send each query to PGlite, with the same parameters production would receive.
- We run the real handlers, not simplified copies.
What it caught the first time
The mandatory pre-deploy check had a hidden bug: statements ending in a scalar SELECT always return one row, and the script expected zero. The test double answered zero and hid the problem. Against a real Postgres it showed up on the first run.
If your test double does not reproduce the real mechanics, it is not testing anything. It is only confirming what you already believed.
Today no migration or new query reaches production without first passing through a real in-memory Postgres.