PostgreSQL
The engine, worked by someone who sends it patches.
Almost everything we build runs on PostgreSQL, and using it well stopped being enough a while ago: we review and fix its core on pgsql-hackers, report what breaks and publish extensions. That changes what we can do for your database: when something fails inside the engine, we know how to read it.
- 7
- contributions in PostgreSQL 19
- 1 as author, 4 as reviewer, 2 as reporter · 12 commits across master and REL_19_STABLE
- 10+
- bugs reported
- to pgsql-bugs, with reproductions; several confirmed by committers
- 5
- extensions on PGXN
- pure SQL: they run on RDS, Aurora and Supabase
Verified against the PostgreSQL repository on 2 October 2026.
What we do with your database
- 01
Performance and plans
Slow queries, indexes that are missing or redundant, and plans that drift over time without anyone noticing. We measure with a median and a confidence interval, not a single number.
- 02
Tenant isolation
Row Level Security design that the database actually enforces, and an audit of the side channels the policies do not cover.
- 03
Migrations
From SQL Server to PostgreSQL and across major versions, with the schema reviewed and the tests run before cutover. Done in production, not in slides.
- 04
Extensions and tooling
Custom pure-SQL extensions for managed services, and the five published on PGXN to watch what fails silently.
- 05
Operations
Backups with tested restores, logical replication, version upgrades and a review of what each release brings before applying it.
Core contributions
Each one links to the commit on git.postgresql.org. The credits are given by the committer, not by us.
- Reporter Fix online checksums revert leftovers
The checksums revert removed a resource manager without bumping XLOG_PAGE_MAGIC. Demonstrated with real 19beta3 WAL.
- Reporter Further post-revert cleanup after online checksums
A mechanical sweep of the thirty revert commits matched the committer’s manual sweep: the same three leftovers, no false positives.
- Reviewer Distinguish publication exclusions in object addresses
Review with the ambiguity case built inside the new code. Also in REL_19_STABLE (91ff666f1d8).
- Reviewer doc: Clarify phase descriptions of pg_stat_progress_repack
REPACK progress phases, reviewed against the real behaviour on 19beta2. Also in REL_19_STABLE (8a2beb5f15f).
- Reviewer Turn "check" into assertion
Review credit for the fix to the TOAST lost update in REPACK, with an isolation test that catches the bug. Also in REL_19_STABLE (2b1d52b1979).
- Reviewer Refresh autovacuum costs while waiting for parallel workers
The switch to SetLatch() came out of a cost measurement sent to the thread. Also in REL_19_STABLE (4a80214270a).
Bugs reported to the project
Every report ships with the minimal case that reproduces it. These are the numbers in PostgreSQL’s public bug tracker.
-
#19686
Rolling back SET TABLESPACE plus an INSERT corrupts the index
with replies from Michael Paquier and Peter Geoghegan
-
#19692
A generic partition-pruning plan delays statement_timeout cancellation
confirmed by David Rowley
-
#19705
One NaN box makes a BRIN index omit unrelated rows
reviewed by John Naylor
-
#19701
A GIN trigram index loses rows at similarity_threshold 0
-
#19641
Unexpected results on an SP-GiST column with a non-deterministic collation
-
#19602
citext split_part silently returns NULL where the core raises an error
-
#19621
json_value with DEFAULT ON EMPTY returns unexpected results
-
#19695
json_value RETURNING jsonb stays NULL after one null evaluation
-
#19715
pg_restore_attribute_stats rejects range statistics for a domain
-
#19507
Constraint name conflicts in partition trees spanning schemas
with a proposed patch
Published extensions
Five, all on PGXN, all pure SQL: they install on RDS, Aurora and Supabase, where a C extension cannot go. They watch what fails with no error, no alert and no log line.
- pg_plan_guard
Detects when a query plan drifts away from the plan you approved. Built on pg_plan_advice, new in PostgreSQL 19.
- pg_recall_guard
Watches vector indexes for recall drift against an approved baseline. pgvector, pgvectorscale and any index with distance operators.
- pg_promise_guard
Finds the guarantees your schema claims and silently does not enforce: invalid unique indexes, NOT VALID constraints, disabled triggers, RLS without FORCE.
- pg_grammar_guard
Compiles a token-level grammar from your live catalog and watches it for drift.
- pg_living_assertions
A registry of the things you claim are true, with the SQL that proves them and the date they were last proven.
Around the core
-
Our own patch in the commitfest
Progress reporting: a debug trace and a test framework. A framework to test progress reporting of long operations, under review in the PostgreSQL commitfest.
Commitfest #7331 -
Co-maintenance of pg_isok
Karl O. Pinc’s data-integrity extension. We contributed isok_lint, which checks saved queries without running them, with a test matrix across PostgreSQL 10 to 19: forty green runs.
codeberg.org/kop/pg_isok -
pgvector and pgvectorscale
An open pull request on pgvector (HNSW prefetch) and pgvectorscale ported to the PostgreSQL 19 beta: it runs in production behind thirty vector and full-text indexes in daily use.
pgvector #1020
How it is measured
- 01
Facts are measured by code, not by opinion: pgbench with a median and a 95 % confidence interval, never a single number.
- 02
Correctness with oracles: SQLancer (NoREC and TLP) finds wrong answers; ASan finds memory corruption.
- 03
Every claim sent to the project carries exact commands and a counter-proof: the test must catch the bug when the fix is reverted.
- 04
Extensions are tested against more than one major version before release.
Questions
Do you work with RDS, Aurora or Supabase?
Yes. The extensions were written in pure SQL precisely for that: they install where a C extension cannot go. And performance, isolation and migration work is the same on a managed service.
Do you migrate from SQL Server?
Yes, and we have done it in production: schema, data, procedures and the application on top. Cutover happens with the tests run and a way back.
What does my project gain from your core contributions?
Two things. When something fails inside the engine, we know how to read it, reproduce it and report it instead of working around it. And the judgement for designing a schema or an isolation policy comes from having seen how they break.
Can you review what we already have without rebuilding it?
That is the usual case. A review of schema, indexes, plans and policies delivers a report with what to change and why; the change is made by your team or by us, as you prefer.
Contact
Got a process falling apart on you?
Tell us which operation you want to put in order. If we can help, we say so with a plan and a timeline; if it is not our thing, we say that too.
Write to us at contacto@betrivasystems.com · We reply within one business day.