Conference talks

¥app.alert(1) is the new alert(1): PDFs as a vector to inject JavaScript in web apps - Luigi Gubello

NDC 2026 · Luigi Gubello · 52 min · year inferred SyncGrid 0

Demonstrates four PDF-triggered XSS vulnerabilities in browser-side PDF viewers — two in PDF.js (CVE-2018-5158 postscript calculator array, CVE-2024 fontMatrix array), plus two in Apryse/PDFTron WebViewer — and shows JavaScript-sandboxed-in-JavaScript always loses to WASM sandboxing. Both PDF.js CVEs share root cause: array type checked, array items not; JS injected via array element. Neither involves PDF's embedded Adobe JavaScript API. Apryse sandbox maps Adobe APIs (console.println → console.log) then blocks via a long denylist of variables set to undefined; payload console.println(delete window; delete confirm; delete document; <payload>) deletes the shadowing variables, restoring browser globals — denylist never blocked delete. Second Apryse bug: annotation form default value passed to unsafe innerHTML, no eval, so it bypasses CSP with unsafe-inline but no unsafe-eval. Exploited against Dropbox's viewer (Apryse-based) but unexploitable: viewer runs in separate cookieless subdomain, iframed, postMessage to main app, CSP via meta tag (so no report-to telemetry). PDF.js sandboxes PDF JavaScript inside WASM — bypass stays inside WASM, no DOM/cookie/localStorage access; Nutrient does the same. Logseq (Electron, outdated PDF.js) demoed as XSS→RCE by calling internal logseq.api git command. Claims nearly every PDF XSS CVE in public databases is a false positive: app.alert(1) is a supported PDF feature, not DOM access — test window.alert instead. Mitigations: CSP with hash + strict-dynamic, isolated cookieless subdomain, disable PDF JavaScript.

SyncGrid: No PDF viewer in stack; angular/.NET untouched.

sshlogin: securely authenticating to remote Linux systems via ... - Ignat Korchagin

NDC 2026 · Ignat Korchagin · 50 min · year inferred SyncGrid 0

Replaces shared root passwords on serial/KVM emergency consoles with a challenge-response OTP that reuses existing SSH keys via ECDH, implemented as a custom Linux PAM auth module at Cloudflare. Verifier generates throwaway ECDH keypair, presents base64 public key as challenge (32 bytes for ED25519, 64→32 compressed for ECDSA, ~45 chars after base64); client computes shared secret from challenge + own SSH private key, server recomputes from authorized_keys public key + throwaway private key; user types back only first 8 bytes of secret (~11-12 chars). Naive sign-the-challenge rejected: ECDSA-256/ED25519 signatures are 64 bytes to type, RSA worse, 20-byte short-signature papers non-standard. HMAC-seed OTPs rejected: TOTP needs clock sync (impossible on dead box) and is valid 30-60s; HOTP counter desyncs on typos, needs window resync, incrementing on failure invites DoS; and shared seeds in authorized_keys-equivalent storage let any root-capable SRE steal a peer's seed and impersonate — worse than a password hash needing offline cracking. Shared password revocation required new OS image rollout, leaving mixed-image fleet where revoked users still get in and legit users guess which password. PAM module wired into /etc/pam.d/login and sshd with [success=2 default=ignore] so password fallback survives bugs; accepts authorized_keys path and minimum response length params. Hardware keys: PIV over PKCS#11 chosen over FIDO2 — FIDO2 SK keys need recent OpenSSH, are disabled in macOS native SSH, can't prove PIN protection, and don't support ECDH at all; YubiKey PIV proves key is PIN-protected at provisioning time, enforcing real 2FA. Ops team complained about copy-paste friction, so a "Clippy" client wrapper intercepts SSH stdin/stdout, detects and color-codes the challenge, parses hostname, and on any keypress + YubiKey touch types the response back — two keystrokes to login. Open-sourcing to Cloudflare GitHub pending internal process.

SyncGrid: linux pam/serial console ops, not our stack

random_page_cost in Postgres - why the default is 4.0 and should you lower it? | POSETTE 2026

POSETTE 2026 · 27 min SyncGrid 6

Reproduces the lost 2000-era benchmark behind Postgres's random_page_cost=4.0 default and measures 27-28 on SSD, 140 on spinning rust — arguing the historical default was never raw I/O ratio but an implicit cache-locality correction, using direct I/O to kill page-cache effects, forced index scans vs seq scans, and per-page timings from EXPLAIN ANALYZE. Cost model dates to ~2000, Tom Lane; seq_page_cost=1.0 is virtual currency, random_page_cost=4.0, CPU costs ~0.01 per tuple, so I/O dominates any real query. Benchmark: 1M-row uniform random table, direct I/O, large enough to defeat caching. Index scan read ~661,000 pages in ~110s → 0.17ms/page random; seq scan read ~45,000 pages in <300ms → 0.006ms/page sequential; ratio ≈27. Same pattern across home and cloud machines, various SSD/RAID configs — all well above 4.0. Raising random_page_cost to 30 fixes isolated queries but hurts whole system: cost model has no concept of active set, doesn't know what's in page cache, ignores concurrency, assigns no cost to memory or to evicting page cache. Sequential scan of 100GB to get 1GB evicts 100GB of cache; index scan reads only the 1GB needed — random I/O is pricier but localized, and 4.0 implicitly encoded that. Conclusion: lowering to 2.0 on SSD is reasonable, but no tool or one-shot experiment can compute the right value; requires iterative tuning under whole-system monitoring. Missing from cost model: async I/O, prefetching.

SyncGrid: Postgres planner tuning: don't set random_page_cost from measured ratio; 2.0 on SSD, tune via monitoring.

pgstats and PostgreSQL 18 (PConf.dev 2026)

PGConf.dev 2026 · 20 min SyncGrid 3

Maps PostgreSQL's cumulative statistics subsystem (pgstats) architecture post-shared-memory rewrite and lands custom stats kinds for extensions in PG19, plus PG18 additions: per-backend stats via pgstat_backend.c, byte-granular pg_stat_io including WAL init/read/write, and parallel-worker planned-vs-launched counters in pg_stat_database and pg_stat_statements. Shared-memory rewrite landed in PG15 (Horiguchi authored, Freund committed), replacing the stats collector process and its synchronous pipes for scalability. Durability is disk-only: file loaded and deleted at startup, flushed at shutdown — crash loses all stats, and autovacuum then gives up on tables with no table-level stats until manual vacuum or fresh stats accumulate; fix targeted at PG19/20, still unfinished. Two stats classes: fixed-size (checkpointer, WAL, SLRU, pg_stat_io) in a startup-allocated shared chunk protected by lightweight locks; variable-size (tables, indexes, functions, databases, replication slots) in a dshash table keyed by (stats kind, database OID, object OID), OID widened 4→8 bytes in PG18. ~12-14 stats kinds. Code lives in src/backend/utils/activity — pgstat.c, pgstat_shmem.c, pgstat_internal.h, one file per kind. Backends accumulate pending stats locally and flush on transaction commit via pgstat_report_stat, so long transactions hide counter updates. PG19 extension API: register a PgStat_KindInfo callback struct via shared_preload_libraries, using reserved or experimental kind IDs registered on the PostgreSQL wiki; in-tree templates exist for both fixed and variable kinds. Motivation: move pg_stat_statements onto in-core pgstats because it does not scale on high-core machines with many calls and relies on a text file.

SyncGrid: Postgres-relevant: crash-loses-stats kills autovacuum on partitions; pg_stat_io byte counters for ingest IO. No action beyond monitoring.

pgcov: Bringing Real Test Coverage to PostgreSQL Code | POSETTE: An Event for Postgres 2026

POSETTE 2026 · 24 min SyncGrid 3

Introduces pgcov, standalone CLI measuring statement coverage of SQL and PL/pgSQL by rewriting function bodies on the fly to insert pg_notify('pgcov', '<file>:<byte-offset>:<byte-length>') before every executable statement, running each test in its own throwaway pgcov_test_<date>_<rand> database, and collecting fired payloads over a dedicated LISTEN connection. No extension, no engine patch, no psql dependency — works on vanilla Postgres, cloud vendors, TimescaleDB; source files unmodified on disk. File naming follows Go convention: *.sql is source, *_test.sql is test. Existing pgTAP and regression tests run unchanged. Two commands: pgcov run -c <conn> <dir> (flags: timeout, parallel test count, output, verbose; default output .pgcov/coverage.json) and pgcov report --format html|lcov|json -o <file>. LCOV feeds Codecov/Coveralls; HTML report mirrors Go's gray/red/green line coloring with a source-file dropdown. Demo product-inventory schema plus add_product(), get_stock_status(), apply_pricing_policy() starts at 50% coverage, 1 test, 592ms; uncommenting a second DO block covering 4 missing branches raises it to 70%. Positioned against plpgsql_check (static, no runtime) and pgTAP (assertions, no execution path). Limits: no C/Python/Perl stored procedures, no per-branch attribution, Postgres 13+, instrumented runs slower than plain regression tests. Planned: merge command, fail-under. Suggested threshold 80%. Repo cybertec-postgresql/pgcov.

SyncGrid: Postgres-side coverage, but SyncGrid logic sits in C#, not PL/pgSQL. Marginal.

pg_textsearch: Native BM25 Full-Text Search in Postgres (PConf.dev 2026)

PGConf.dev 2026 · 26 min SyncGrid 2

Builds pg_textsearch, a Postgres-licensed BM25 ranked keyword-search extension, by porting Lucene/Tantivy architecture — LSM-tree index (shared-memory memtable → leveled on-disk immutable segments), block-max WAND query evaluation, block-wise posting compression, field-norm quantization — while reusing Postgres to_tsvector as tokenizer for 29+ language configs. Problem: Postgres FTS since 8.3 does Boolean exact match only, no index support for ranked queries, and GIN update performance tanks from inverted-index write amplification (scattered index writes blow page IO up by ~page-size factor); BM25's global corpus statistics (term frequency, IDF, doc-length normalization) don't fit GIN. SQL surface: create index with text config param, <eyeball> similarity operator, mandatory ORDER BY + LIMIT (limit feeds the evaluation algorithm); planner hook rewrites query to name the index explicitly — queries cannot run without the index since corpus stats live there. Pre-filtering (selective WHERE → row-at-a-time scoring) and post-filtering with exponential limit backoff. Supports partitioned tables, expression/partial indexes, parallel bulk indexing, physical+logical replication. Missing: background compaction, faceted/multi-column search, positional/phrase queries (deliberately skipped — hybrid search with vector fusion makes phrases less important). MS MARCO Passages, 138M docs / ~50GB: 81ms avg latency vs ParadeDB's 700ms, ~9x throughput, though speaker concedes ParadeDB has since optimized.

SyncGrid: Postgres extension, but ranked text search not a metering workload. LSM write-amplification framing only mild interest.

pg_stats: How Postgres Internal Stats Work | POSETTE: An Event for Postgres 2026

POSETTE 2026 · 26 min SyncGrid 3

Traces why SELECT * FROM customers WHERE state='CA' on a 1M-row table with an index still seq-scans, by reading pg_stats columns n_distinct, null_frac, correlation, most_common_vals/most_common_freqs, and histogram_bounds, then fixing bad estimates with ALTER TABLE ... ALTER COLUMN ... SET STATISTICS 1000 and CREATE STATISTICS. pg_stats is a human-readable view over table pg_statistic; Postgres naming trivia — plural/stat names are views, singular are tables. ANALYZE populates it. n_distinct = -1 means every value unique (primary key). correlation near 0 = data randomly spread on disk, pushes planner to seq scan; near ±1 favors index scan. CA at 17.4% frequency, TX 11.65%: seq scan cost 19,000, est 17,000 rows vs 17,200 actual. Wyoming (4,000 rows) picks index scan at cost 13,000. Forcing SET enable_seqscan=off on the CA query yields index scan costing 32,000 — confirming planner chose correctly. Costs driven by random_page_cost, seq_page_cost, cpu_tuple_cost. Default 100 histogram buckets ≈ 2 months per bucket on signup_date; 1000 buckets ≈ 2 days, max 10,000 — tradeoff is slower ANALYZE, so raise per column only. Multi-column correlation: city='Cheyenne' AND state='WY' estimates 8 rows vs 4,012 actual because planner multiplies independent probabilities; CREATE STATISTICS ... (dependencies, ndistinct) + ANALYZE brings estimate to 4,087. Six-step debug recipe: compare estimated vs actual rows at deepest EXPLAIN ANALYZE node, inspect pg_stats, re-ANALYZE after batch loads/migrations when autovacuum lags, raise statistics target, add extended statistics, then rewrite query.

SyncGrid: Steal CREATE STATISTICS dependencies for correlated tenant/meter columns; rest is known planner basics.

pg_plan_advice: Plan Stability and User Planner Control for PostgreSQL? (PConf.dev 2026)

PGConf.dev 2026 · 50 min SyncGrid 6

Builds pg_plan_advice, a PostgreSQL 19 contrib module that generates and re-applies a mini-language describing planner decisions (join order, join methods, scan methods, Gather/Gather Merge placement) for plan stability, using a roundtrip-safe relation identifier syntax (alias#occurrence/schema.partition@planname), parenthesized join groups, and a new pgs_mask path-generation-strategy bitmask that disables paths at whole-plan, baserel, join, or per-join-method granularity. EXPLAIN gains a PLAN_ADVICE option printing the advice string; advice re-enters via SET pg_plan_advice.advice, a companion pg_stash_advice module mapping query IDs to strings (deployable with zero app changes via ALTER ROLE/DATABASE SET), or a pluggable advisor hook returning a string or NULL per query. Generation required core changes because final plans lose information: result nodes now record which RTI they replace, plus fixes for stripped SubqueryScan boundaries and single-child Append/MergeAppend removal — small annotations stored where the executor ignores them, so plans grow slightly but run no slower. Subqueries also had to be named before planning finishes so advice can match mid-planning. Enforcement runs the normal planner and disables incompatible paths; PostgreSQL 18's change to compare disabled-ness before cost closes the old "disabled path still wins" gap. Impossible advice never errors — it yields a terrible plan. Future: cardinality advice, aggregation control, negative advice, random-advice fuzzing of plans.

SyncGrid: Postgres 19 plan stability for critical time-series queries; pin plans by query ID, zero app change.

pg_lake: Postgres as a lakehouse | POSETTE: An Event for Postgres 2026

POSETTE 2026 · 25 min SyncGrid 6

pg_lake, Apache-licensed Postgres extension, makes Iceberg a native table format (CREATE TABLE ... USING iceberg) plus Parquet/CSV/JSON object-store access, delegating analytical queries to an out-of-process DuckDB server speaking the Postgres protocol. Started early 2024 at Crunchy Data, open-sourced November, Crunchy acquired by Snowflake June last year; now core to Snowflake Postgres service. Iceberg tables support insert/update, ADD/DROP COLUMN, sequences, triggers, constraints, stored procedures; no indexes, no foreign keys, no row-level security (indexes proposed upstream). Transactionality comes from a catalog database holding the current top-level metadata file pointer — failed final catalog update rolls the transaction back. Background worker compacts small files every 10 minutes (e.g. several 1MB files into one 20MB file). DuckDB can't live in every Postgres backend process (big thread pool, high memory), so one sidecar server serves all sessions, holds S3 credentials, fetches partial data files, and caches files locally. Companion extension pg_incremental drives once-only processing over sequence ranges, time buckets, or object-store file lists (batches of 100 files), waiting for older in-flight transactions before advancing a range. Patterns: archive 7-day Postgres partitioned event table into Iceberg every minute; pg_cron job every 10s draining a Postgres queue table into Iceberg; ingest JSON/log files from object storage into heap or Iceberg tables.

SyncGrid: Cold time-series archive: Iceberg tables + pg_incremental sequence pipelines replace hand-rolled JSON cold path. No indexes/RLS hurts multi-tenant.

pg_duckdb in Action: Accelerating Analytics on Azure Database for PostgreSQL | POSETTE 2026

POSETTE 2026 · 24 min SyncGrid 6

Demos pg_duckdb 1.1.0 (embedding DuckDB 1.4.3) on Azure Database for PostgreSQL Flexible Server, cutting TPC-H scale-factor-5 query times 2-7x by hooking the Postgres planner and routing eligible SELECTs to DuckDB's columnar vectorized executor, plus reading/writing Parquet on Azure Blob directly from SQL. Extension enabled via azure.extensions + shared_preload_libraries, server restart, CREATE EXTENSION. Measured on 5GB lineitem / 1GB orders / 145MB customer: TPC-H Q1 26.6s Postgres vs 11.1s DuckDB (2.4x); Q13 7.7s vs 4.1s (~2x); multi-COUNT(DISTINCT) over orders 1993-1996 grouped by order priority 15.7s vs 2.3s (~7x). Three activation triggers: duckdb.force_execution=on, any read_parquet/read_csv/read_json call, else silent fallback to the Postgres planner when DuckDB can't handle the query (INSERT, unsupported features) — no errors, same wire protocol, unchanged SQL. create_azure_secret registers blob credentials; Parquet scanned in place, no ingest, no ETL. Hybrid analytics joins a live Postgres watchlist table with blob Parquet in one statement, then writes results back as Parquet. Stated engine tradeoffs: DuckDB has no transactions and no concurrent OLTP, optimized for one big query at a time; Postgres parallelism bounded. Available on Flexible Server 14-18.

SyncGrid: Steal for cold JSON/archive tier: query Parquet in place, join hot Postgres. Managed-Azure-only demo, no tenant-schema story.

[Sponsor Track] Zsolt Parragi: TDE as an Extension: A Different Path for PostgreSQL Encryption

PGConf EU 2026 · 45 min SyncGrid 3

Percona built pg_tde, open-source transparent data encryption for PostgreSQL shipped as an extension plus a few-hundred-line core fork, after abandoning a first prototype that copied the heap table access method (tuple-level encrypt/decrypt) because sequential-scan throughput fell to ~60% of unencrypted even after 3x optimization, versus ~10% drop advertised by commercial solutions. First prototype encrypted tuples inside the buffer pool — strictly better than normal TDE since plaintext lived only briefly in the connection process — but caused data corruption on multi-table statements, then memory spikes when fixed by holding decrypted tuples until statement end (20GB table seq scan = whole table in RAM); final fix kept one decrypted row per query participant. Indexes were never encrypted, which is why pgbench/sysbench showed only a few percent loss: those tests are index-scan bound. Second prototype hooks the storage manager (Neon's extensibility patch, already used by other vendors) plus new WAL extension points. Covers tables, indexes, sequences; misses WAL-by-default granularity (whole-WAL setting, global key, breaks multi-tenancy), temporary files, system tables. Event triggers on DDL set per-file encryption flags; VACUUM FULL isn't DDL so rewrote encrypted files as plaintext until sanity checks added. Mixed encrypted/unencrypted partitions or typed tables in one ALTER: errors out. WAL rewritten with rotated latest key caused corruption detectable only on read. pg_waldump forked as pg_tde_waldump. Two-level keys: per-object keys in database, master key external. Production-ready, requires Percona's fork. PG18 AIO unsupported.

SyncGrid: Postgres TDE needs Percona fork; multi-tenant schema encryption still open. Watch, don't adopt.

[Sponsor Track] Vincent O'Dea: Exploring new enhancements and improvements Fujitsu has delivered to

PGConf EU 2026 · 51 min SyncGrid 2

Catalogs Postgres logical replication upgrades from PG15 to proposed PG19: conflict detection types, parallel apply halving apply time (120s→60s on 1M-row×10-cycle insert workload), pg_create_subscriber beating COPY-based sync above ~500MB tables, and proposed EXCEPT TABLE/column exclusion in publications. Pre-15 conflicts killed the apply worker into an infinite retry loop; PG15 added disable_on_error, ALTER SUBSCRIPTION ... SKIP (lsn), pg_stat_subscription_stats, and verbose logs exposing origin + finished LSN (needed for the riskier pg_replication_origin_advance, where an over-shot LSN loses data). PG18 added seven conflict types: insert_exists, update_exists, update_origin_differs, update_missing, delete_origin_differs, delete_missing, multiple_unique_conflicts — detection only, logged with schema/table/local vs remote tuple; enable track_commit_timestamp on subscriber for timestamps. Unreleased/community-pending: update_deleted conflict type, which searches dead tuples for the old value to distinguish "not yet inserted" from "already deleted"; requires new subscription option retain_conflict_info (renamed retain_dead_tuples) plus max_conflict_retention_duration, which invalidates the retention slot when the apply worker falls behind so vacuum can proceed. Also proposed: resolvers (apply_remote, apply_or_skip, apply_or_error, keep_local, last_update_wins, skip, error), a delta resolver summing concurrent balance increments (100→200 and 100→300 yields 400), user-defined resolvers, and a conflict history table. Parallel apply default for large transactions in PG18, targeted for all transactions in PG19, with fallback to single-threaded when no workers free.

SyncGrid: Postgres in stack, but no logical replication or multi-master; pg_create_subscriber only if upgrade path needed.

[Sponsor Track] Torsten Steinbach: From Transactions to Intelligence: Postgres for Open AI & Analyti

PGConf EU 2026 · 50 min SyncGrid 2

EDB architect lays out three strategies for pushing Postgres from OLTP into analytics/AI: organic (WarehousePG MPP fork of last open-source Greenplum after Broadcom closed it, built-in ML training, disk-based vector indexes with GPU-accelerated build), hybrid (DataFusion as vectorized columnar push-down engine behind Postgres, Spark via Spark Connect for scale-out, Iceberg REST catalog via Lakekeeper, LLM serving), and augmenting (MCP server + text-to-SQL). Vector claim: pgvector HNSW breaks down at 400M vectors; vectorchord with GPU-accelerated clustering-based index build gives large build-time speedup plus higher single-thread QPS and ~few-thousand vs ~1000 QPS at 100M vectors, 768 dims. AIDB extension does chunking, embedding generation, and feature extraction inside Postgres — embedded CPU models in a Postgres worker for small scale, or external/hosted GPU model serving (Hugging Face, OpenAI, vLLM) on the PostgresAI Kubernetes platform; can catalog S3 buckets as "volumes" and embed objects without loading them. Demo: pg-mcp (forked from an abandoned repo after the startup was acquired) driving Nvidia Nemotron 45B, tools list_schemas/list_objects/explain_query/run_query, extended to read table and view COMMENTs so business questions resolve to the right view. Speaker notes LLM nondeterminism — same prompt applied a 20-review cutoff in one run, only suggested it in another.

SyncGrid: Postgres MCP server for schema/index/health introspection worth trying; rest is EDB vendor platform, no vector or warehouse need.

[Sponsor Track] Michal Nosek: Lessons from two decades of hacking the proprietary value into open so

PGConf EU 2026 · 54 min SyncGrid 2

Percona enterprise architect catalogs nine field lessons on porting proprietary database features into open source, drawn from MySQL, MongoDB, Valkey and Postgres work — product-manager function beats GitHub upvote counting because enterprise users are outnumbered and legally silenced, proprietary feature sets are legitimate roadmap inspiration, and tiny gaps block adoption outright. Examples: Postgres 18 shipped OAuth 2.0 but lacked an OIDC validation library, so Okta end-to-end setup failed; Percona built and published one days before the talk, already got a bug report plus a patch. A bank on Kerberos-authenticated MongoDB found the monitoring agent lacked Kerberos; changing bank auth was estimated at four years, so Percona added Kerberos to the agent instead. PCI DSS 4.0 pushed PGTDE (Postgres transparent data encryption) — spec text says storage-level encryption alone is insufficient for primary account numbers, extra means required. A credit-card issuer dropped Valkey because Dynatrace certification covered only Redis/Redis Enterprise APIs; they wrote a Prometheus-format push agent instead. Fragmentation: a Swiss financial RFP listed tens-to-hundreds of extensions/backup/HA tools, unsupportable end-to-end by any vendor. Enterprises cap at latest major minus one (Postgres 17, not 18), rarely test pre-stable, still run MySQL 5.7 (EOL 2023); Kubernetes N-2 with 15-week cadence gives ~14-month version lifetime, which alone disqualifies Kubernetes for databases at some orgs.

SyncGrid: Postgres 18 OIDC validation library gap relevant to Keycloak/BFF auth; rest is vendor strategy talk.

[Sponsor Track] Maxim Sobolevskiy: DataGrip: A Powerful IDE for PostgreSQL

PGConf EU 2026 · 49 min SyncGrid 1

Vendor demo of JetBrains DataGrip for Postgres: introspection levels (1=names only/fast, 2=no source code, 3=everything) drive code completion, join autocompletion from foreign keys, and AI context. Query consoles are being removed next release in favor of plain query files plus scratch files, with migration dialog. Features shown: virtual foreign keys (IDE-level, for DBs lacking real FKs) to enable join completion and diagrams; alt+enter refactorings (expand column list, qualify identifier, introduce table alias, query→subquery→CTE); live templates with variables; abbreviation completion (ai→actor_id, ob→order by); per-data-source color tagging for prod vs test; read-only data source flag blocking inserts/updates. Data editor: client-side vs server-side sort/filter distinction, ctrl+F client text search across page, preview update showing generated DML before submit, value pane formatting XML/JSON, value-based cell coloring (sequential/divergent). Scriptable extractors (Groovy) for export/clipboard — where-clause extractor emits IN (...); aggregates pane extensible by script, speaker generated some with AI. Cross-database result-set comparison and copy-to-database materialization (Postgres result → MySQL/SQLite table). Unreleased EAP: explain-plan button with tree/diagram view plus AI "analyze plan" giving TLDR and optimization suggestions. Free for non-commercial use, unverified, AI training opt-out; DataGrip functionality bundled in all commercial JetBrains IDEs.

SyncGrid: IDE demo, no engineering technique. Maybe virtual FK + explain-plan AI, nothing to build.

[Sponsor Track] Hans-Jürgen Schönig: What we built with Open Source

PGConf EU 2026 · 38 min SyncGrid 1

Cybertec's Schönig argues commercial Postgres work fills gaps open source cannot close in time, citing transparent data-at-rest encryption (file, WAL, backup, replay, on-the-fly encrypt/decrypt, key rotation, key-manager integration, via a 'replication proxy' allowing different keys per data center), a Kubernetes/OpenShift platform bundling PGEE, migration toolchain, low-code Oracle-app replacement and MSSQL-compatible Postgres, and SCALEFIELD Secure for cross-engine audit/compliance extraction. Drivers: DORA, HIPAA, African financial regulation. Scale is the real problem, not microseconds — one customer runs 11,000 on-prem, airgapped systems; a restart once killed 800 phone calls; assembly lines, grids, air traffic can't take downtime. Migrating 1,000 Oracle databases is logistics not tech: original authors dead, app owners refuse, source schema keeps changing mid-project, so they do bulk assessment via cloned system catalogs into a central repository plus change tracking, and LLM code explanation/pre-translation because you can't hire 10,000 migration experts. Upstream contributions: multi-data-center Kubernetes failover merged into the Zalando operator; in progress by year-end, Patroni major-version upgrades without full replica resync (customer at 200TB can't run 6x pg_basebackup). An optimizer patch took 8-9 years to land. Some code stays closed — customers paid, or ideological rejection upstream. Q&A: hardest part of regulation is people, not tech (revoking DBA root access); UK regulators demand a documented CVE-scanned, certified build pipeline.

SyncGrid: Vendor pitch; only reusable bit: audited CVE-scanned build pipeline for regulated grid customers.

[Sponsor Track] Dr. Luigi Nardi: DBtune: AI-driven performance tuning for all PostgreSQL flavors

PGConf EU 2026 · 48 min SyncGrid 5

Pitches DBtune, an ML service that auto-tunes ~18 Postgres server parameters (up from 12 in V2) via an open-source Go agent reading pg_stat_statements plus CPU/memory/disk metrics, feeding an online-retrained optimizer that rewrites postgresql.conf (or calls RDS/Aurora/GCP/Azure APIs) over ~30 iterations of 5-minute windows in 2-3 hours. Exhaustive grid sweeps over max_parallel_workers_per_gather × random_page_cost show optimum sits bottom-right for Epinions but bottom-left for TPC-H — order-of-magnitude runtime spread, and copying one app's config onto another lands in the bad region. Manual sequential knob-by-knob tuning only moves along coordinate axes, missing diagonal optima; 12 parameters ≈ 1 trillion combinations, PG18 ships ~400 parameters total (~20 matter). TPC-C on RDS: tuned m5.2xlarge reaches the throughput of a doubled instance (~850→~1700 tps), saving ~$8k/yr per instance. Anonymized insurance customer, already hand-tuned by a DBA: 2.5x lower average query runtime. Demo run: baseline 140ms → 109ms after one iteration (random_page_cost 4→1.1, effective_io_cache, maintenance_work_mem changes), best at iteration 25, ~2x. V3 adds "workload fingerprint" — picks the few queries dominating the workload (one UPDATE = 96% in Resource Stresser) to denoise the optimization signal, since raw avg query runtime fluctuates day to day. No index, query, or session-level (SET) tuning; pg_stat_statements overhead accepted as a few percent. Async I/O tuning for PG18 planned.

SyncGrid: Postgres knob autotuning per-workload; steal fingerprint idea — pick dominant queries as tuning signal. Vendor SaaS, cost unclear.

[Sponsor Track] Burak Yucesoy: Unlock PostgreSQL’s True Performance with Local SSDs

PGConf EU 2026 · 46 min SyncGrid 6

Argues local NVMe should be default Postgres storage, backed by same-hardware benchmarks on UpCloud: PGBench/TPC-B 6x more TPS, TPC-C 8.5x, TPC-H ~8x faster than remote/network-attached storage; customers migrating from remote storage hit 3x better performance at half CPU and half memory. Remote storage won by historical accident — AWS pooled storage over network to fix HDD failure rates and single-head random-IO limits, then Kubernetes/managed-Postgres stacks got built on top. NVMe annual failure rate 2-3 orders of magnitude below HDD, and prices now affordable, so the 15-year-old cloud storage model is at an inflection point. Remote storage keeps three advantages — elasticity, durability, transparency — but all three benefit the operator, not the end user; UpCloud negates them by building a new standby, replicating, and cutting over for any scale/upgrade/disk-end-of-life event. Local NVMe resiliency via Postgres streaming replication (sync or async), block mirroring, or WAL shipping; both architectures pay a network hop for replication, local just skips the compute→storage hop. Cost claim: EC2 instance + local NVMe is cheaper than same-spec + EBS, since EBS replicates ~5x under the hood. Benchmarks ran on Postgres 17, untuned identically on both sides (random_page_cost, io_concurrency left alone, which the speaker says would widen the gap); Postgres 18 async IO expected to help remote more, gap shrinking to maybe 6-7x. Only UpCloud, PlanetScale and one other offer managed local-NVMe Postgres; no hyperscaler does. ~16 slots x 15-30TB disks ≈ half petabyte ceiling.

SyncGrid: Local NVMe vs EBS numbers for time-series Postgres; check disk class under hot partitions.

[Sponsor Track] Adam Wolk: Pushing Postgres Forward: From Open Source Contributions to Intelligent T

PGConf EU 2026 · 42 min SyncGrid 4

Microsoft sponsor talk inventorying Postgres upstream contributions and Azure product features: 7 of 31 Postgres committers and 90 open-source contributors employed by Microsoft, 540 of 3,320 PG18 commit attributions, ~1,000 of 5,000+ PG18 reviews (18% of features). Upstream work: async I/O in PG18 (io_uring on Linux, portable worker processes elsewhere) via read streams, replacing per-8KB-page sequential read syscalls with vectored batched reads; OAuth token-auth infrastructure; partition planner speedups — 3x faster planning at ~56 partitions, more at thousands; aggressive-vacuum cost amortization via eager page scanning during regular vacuum; faster database cloning; memory-management optimizations for matviews, window aggregates, CTEs; group-by/hash-join speedups; redundant GROUP BY column removal via unique indexes; early groundwork on multithreading (locale support first), citing 1990 Stonebraker paper calling process-per-connection a "quick hack". Products: VS Code PostgreSQL extension (200k+ installs, schema visualization, IntelliSense, Copilot chat agent requiring explicit approval before DDL execution); Citus 13.2 with snapshot-based node addition avoiding network rebalance, local query execution speedups, Elastic Clusters on Flexible Server with compatibility matrix across 70+ extensions (TimescaleDB incompatible — both hook the planner); DiskANN vector index claimed to beat HNSW/IVFFlat on latency, accuracy, TPS and memory, plus product quantization; SQL semantic operators (azure_ai.generate, is_true, extract, rank); autonomous index tuning surfacing recommendations only when ≥1 query improves 20% and no query regresses >10%.

SyncGrid: PG18 async io_uring + 3x partition planner speedup argue upgrade; rest Azure-only, Citus/vector irrelevant.

Zero-Knowledge Proofs: Simultaneously ensuring integrity and privacy - Tjerand Silde

NDC 2026 · Tjerand Silde · 44 min · year inferred SyncGrid 0

Surveys zero-knowledge proofs as deployed cryptography — correctness, soundness (small controllable cheating probability, tied to AES/RSA-level hardness), zero-knowledge — and maps them onto five shipped systems: FIPS 204 ML-DSA lattice signatures (a Fiat-Shamir'd ZK proof of knowledge of small secret vectors S1, S2 against public matrix A), e-voting (proof ciphertext encrypts one of a valid vote list, verifiable shuffle via re-randomization by encrypting zero plus permutation proof, proof of correct decryption key), Zcash shielded transactions (sender, receiver, amount encrypted; proof funds exist and are unspent), anonymous credentials for the EU digital identity wallet (prove passport signed by Norwegian police shows birth date before threshold, nothing else; repeated logins unlinkable), and verifiable ML (prove model trained/evaluated on given data without revealing model or inputs). Norwegian COVID contact-tracing app used a one-time re-randomizable token: positive-test certificate randomized exactly once into an unlinkable valid token, plus ZK proof of validity. zk-SNARKs give constant-size ~1KB proofs and millisecond verification regardless of statement size, cost shifted to prover time/memory — powerful server proves, mobile verifies. Standardization ad hoc: NIST process ongoing, ZKProof community, Ethereum Foundation. Education-oriented open source: Baby Snark (Python), Aurora. Pairs with FHE (compute on ciphertext) and MPC (joint statistics, e.g. salaries) where ZK enforces honest behavior.

SyncGrid: crypto research survey, out of stack; no .NET/postgres/time-series lever