PostgreSQL
El motor, trabajado por quien le manda parches.
Casi todo lo que construimos corre sobre PostgreSQL, y hace tiempo que no nos alcanza con usarlo bien: revisamos y reparamos su núcleo en pgsql-hackers, reportamos lo que se rompe y publicamos extensiones. Eso cambia lo que podemos hacer por tu base de datos: cuando algo falla adentro del motor, sabemos leerlo.
- 7
- aportes en PostgreSQL 19
- 1 como autor, 4 como revisor, 2 como reportero · 12 commits entre master y REL_19_STABLE
- 10+
- bugs reportados
- a pgsql-bugs, con reproducción; varios confirmados por committers
- 5
- extensiones en PGXN
- en SQL puro: corren en RDS, Aurora y Supabase
Verificado contra el repositorio de PostgreSQL el 2 de octubre de 2026.
Qué hacemos con tu base
- 01
Rendimiento y planes
Consultas lentas, índices que sobran o faltan, y planes que derivan con el tiempo sin que nadie lo note. Medimos con mediana e intervalo de confianza, no con un número suelto.
- 02
Aislamiento entre clientes
Diseño de Row Level Security que la base aplica de verdad, y auditoría de los canales laterales que las políticas no cubren.
- 03
Migraciones
De SQL Server a PostgreSQL y entre versiones mayores, con el esquema revisado y las pruebas corridas antes del corte. Hechas en producción, no en diapositivas.
- 04
Extensiones y herramientas
Extensiones a medida en SQL puro para servicios gestionados, y las cinco publicadas en PGXN para vigilar lo que falla en silencio.
- 05
Operación
Respaldo con restauración probada, replicación lógica, actualización de versión y revisión de lo que trae cada release antes de aplicarla.
Aportes al núcleo
Cada uno enlaza al commit en git.postgresql.org. Los créditos los pone el committer, no nosotros.
- Reportero Fix online checksums revert leftovers
El revert de checksums quitó un gestor de recursos sin subir XLOG_PAGE_MAGIC. Demostrado con WAL real de 19beta3.
- Reportero Further post-revert cleanup after online checksums
Un barrido mecánico de los treinta commits del revert empató con el barrido manual del committer: mismos tres restos, sin falsos positivos.
- Revisor Distinguish publication exclusions in object addresses
Revisión con el caso de ambigüedad construido dentro del código nuevo. También en REL_19_STABLE (91ff666f1d8).
- Revisor doc: Clarify phase descriptions of pg_stat_progress_repack
Fases del progreso de REPACK, revisadas contra el comportamiento real en 19beta2. También en REL_19_STABLE (8a2beb5f15f).
- Revisor Turn "check" into assertion
Crédito de revisión del fix a la pérdida de actualizaciones de TOAST en REPACK, con un test de aislamiento que atrapa el bug. También en REL_19_STABLE (2b1d52b1979).
- Revisor Refresh autovacuum costs while waiting for parallel workers
El cambio a SetLatch() salió de una medición de costo enviada al hilo. También en REL_19_STABLE (4a80214270a).
Bugs reportados al proyecto
Cada reporte va con el caso mínimo que lo reproduce. Son los números del rastreador público de PostgreSQL.
-
#19686
Deshacer SET TABLESPACE más un INSERT corrompe el índice
con respuestas de Michael Paquier y Peter Geoghegan
-
#19692
Un plan genérico con poda de particiones retrasa la cancelación por statement_timeout
confirmado por David Rowley
-
#19705
Una caja NaN hace que un índice BRIN omita filas no relacionadas
con revisión de John Naylor
-
#19701
Un índice GIN de trigramas pierde filas con similarity_threshold en 0
-
#19641
Resultados inesperados en una columna SP-GiST con colación no determinista
-
#19602
citext split_part devuelve NULL en silencio donde el núcleo lanza error
-
#19621
json_value con DEFAULT ON EMPTY devuelve resultados inesperados
-
#19695
json_value RETURNING jsonb queda en NULL tras una evaluación nula
-
#19715
pg_restore_attribute_stats rechaza estadísticas de rango para un dominio
-
#19507
Conflicto de nombres de restricciones en árboles de particiones entre esquemas
con parche propuesto
Extensiones publicadas
Cinco, todas en PGXN, todas en SQL puro: se instalan en RDS, Aurora y Supabase, donde una extensión en C no entra. Vigilan lo que falla sin error, sin alerta y sin registro.
- pg_plan_guard
Detecta cuándo el plan de una consulta se aleja del plan que aprobaste. Sobre pg_plan_advice, nuevo en PostgreSQL 19.
- pg_recall_guard
Vigila la deriva de recall de los índices vectoriales contra una línea base aprobada. pgvector, pgvectorscale y cualquier índice con operadores de distancia.
- pg_promise_guard
Encuentra las garantías que tu esquema declara y no aplica: índices únicos inválidos, restricciones NOT VALID, triggers deshabilitados, RLS sin FORCE.
- pg_grammar_guard
Compila una gramática a nivel de token desde tu catálogo vivo y vigila su deriva.
- pg_living_assertions
Un registro de las cosas que afirmas que son ciertas, con el SQL que lo prueba y la fecha en que se probó por última vez.
Alrededor del núcleo
-
Parche propio en el commitfest
Progress reporting: a debug trace and a test framework. Un marco para probar el reporte de progreso de operaciones largas, en revisión en el commitfest de PostgreSQL.
Commitfest #7331 -
Co-mantención de pg_isok
Extensión de integridad de datos de Karl O. Pinc. Aportamos isok_lint, que revisa las consultas guardadas sin ejecutarlas, con una matriz de pruebas en PostgreSQL 10 a 19: cuarenta corridas verdes.
codeberg.org/kop/pg_isok -
pgvector y pgvectorscale
Pull request abierto en pgvector (prefetch en HNSW) y pgvectorscale portado a la beta de PostgreSQL 19: corre en producción detrás de treinta índices vectoriales y de texto completo en uso diario.
pgvector #1020
Cómo se mide
- 01
Los hechos los mide el código, no una opinión: pgbench con mediana e intervalo de confianza del 95 %, nunca un número suelto.
- 02
Correctness con oráculos: SQLancer (NoREC y TLP) encuentra respuestas incorrectas; ASan encuentra corrupción de memoria.
- 03
Toda afirmación enviada al proyecto lleva comandos exactos y contraprueba: el test tiene que detectar el bug al revertir el fix.
- 04
Las extensiones se prueban contra más de una versión mayor antes de publicarse.
Preguntas
¿Trabajan con RDS, Aurora o Supabase?
Sí. Las extensiones se escribieron en SQL puro justamente para eso: se instalan donde una extensión en C no entra. Y el trabajo de rendimiento, aislamiento y migración es el mismo en un servicio gestionado.
¿Hacen migraciones desde SQL Server?
Sí, y las hemos hecho en producción: esquema, datos, procedimientos y la aplicación encima. El corte se hace con las pruebas corridas y un camino de vuelta.
¿Qué gana mi proyecto con que aporten al núcleo?
Dos cosas. Cuando algo falla adentro del motor, sabemos leerlo, reproducirlo y reportarlo, en vez de rodearlo. Y el criterio para diseñar un esquema o una política de aislamiento viene de haber visto cómo se rompen.
¿Pueden revisar lo que ya tenemos sin rehacerlo?
Es lo habitual. Una revisión de esquema, índices, planes y políticas entrega un informe con lo que cambiar y por qué; el cambio lo hace tu equipo o nosotros, como prefieras.
Contacto
¿Tienes un proceso que se te está cayendo a pedazos?
Cuéntanos qué operación quieres ordenar. Si podemos ayudar, lo decimos con un plan y un plazo; si no es lo nuestro, también lo decimos.
Escríbenos a contacto@betrivasystems.com · Respondemos dentro de un día hábil.