#postgresql

How Vibe.co handles billions of ad impressions with ClickHouse Cloud

Vibe.co, nền tảng quảng cáo TV kết nối bị Walmart mua lại, đã chuyển từ Postgres sang ClickHouse Cloud để xử lý hàng tỷ lượt hiển thị quảng cáo. Giải pháp này loại bỏ lớp tiền tổng hợp kém ổn định, mở rộng dữ liệu lưu trữ từ ~100 GB lên hơn 2 TB mà không cần thay đổi kiến trúc, đồng thời cung cấp 90%+ báo cáo chiến dịch cho khách hàng trong dưới 100ms.

Những kỹ thuật tối ưu hóa quy mô lớn của Vibe.co cho ClickHouse Cloud sẽ giúp bạn hiểu cách xử lý dữ liệu thời gian thực hiệu quả, giảm chi phí và tăng tốc độ báo cáo khi làm việc với lượng dữ liệu khổng lồ.

New Postgres Language Server: postgres-lsp

postgres-lsp là một triển khai mới theo giao thức Language Server (LSP) dành cho SQL và PL/pgSQL của PostgreSQL, sử dụng tree-sitter-postgres. Nó cung cấp các tính năng IDE như chẩn đoán lỗi, gợi ý ngữ nghĩa, điều hướng định nghĩa, định vị tham chiếu, hoàn thành thông minh, hỗ trợ chữ ký, đổi tên, hành động mã hóa và định dạng SQL với nhiều kiểu cài đặt sẵn.

Lập trình viên PostgreSQL nên đọc bài này để khám phá cách postgres-lsp nâng cao hiệu suất IDE với các tính năng như hoàn thành ngữ cảnh, định nghĩa và tham chiếu nhanh, và định dạng SQL theo nhiều phong cách chuyên nghiệp, thay vì phụ thuộc vào các công cụ cũ dựa trên regex.

Optimising Polymorphic Associations in PostgreSQL: Help the planner avoid performance cliffs

Các association đa hình (polymorphic associations) trong PostgreSQL gây ra suy giảm hiệu suất nghiêm trọng do O(M×N) phép join không cần thiết, nhưng ba bản vá đang được thảo luận (Result Filter, Sort Pushdown, SubLink relocation) sẽ giải quyết vấn đề này bằng cách tối ưu hóa bộ lọc, sắp xếp sớm và chuyển đổi EXISTS thành SEMI-JOIN. Ngoài ra, thống kê selectivity (CREATE STATISTICS) cũng đang trong giai đoạn thử nghiệm để cải thiện hiệu suất truy vấn.

Lập trình viên cần đọc bài này để hiểu cách tối ưu hóa các mối liên kết đa hình trong PostgreSQL, giúp tránh mất hiệu suất khi ORM tự động tạo các join không hiệu quả, từ đó cải thiện tốc độ xử lý các truy vấn lớn.

How Five PostgreSQL Optimizations Sped Up Our Dashboard

Nhóm kỹ thuật GitGuardian đã giảm thời gian phản hồi p95 của dashboard từ 8 giây xuống 1 giây nhờ 5 tối ưu hóa PostgreSQL trên hệ thống Django, bao gồm: deferred JOINs bằng prefetch_related, đếm bất đồng bộ, replica đọc premium, cải tiến full-text search (pg_trgm), và denormalization để hỗ trợ composite indexes. Việc nâng cấp lên PostgreSQL 18 cũng mang lại lợi ích nhỏ. Họ sử dụng OpenTelemetry và EXPLAIN ANALYZE để theo dõi tiến trình.

Nếu bạn đang làm việc với ứng dụng backend sử dụng PostgreSQL và Django, bài viết này sẽ giúp bạn tìm hiểu cách tối ưu hóa hiệu suất dashboard hiệu quả bằng những kỹ thuật cụ thể, từ đó tiết kiệm thời gian và chi phí phát triển.

Looking Forward to Postgres 19: Logically Sequenced

Postgres 19 bổ sung hỗ trợ sao chép logic (logical replication) cho sequences, vốn bị loại trừ suốt gần một thập kỷ do tính phi giao dịch. Tính năng mới tự động đồng bộ sequences tại các thời điểm xác định như tạo/refresh subscription, cùng công cụ hỗ trợ như hàm pg_get_sequence_data() và cột sync_seq_error_count. Cách tiếp cận này tương tự pglogical nhưng được tích hợp sẵn vào Postgres.

Lập trình viên cần đọc bài này để hiểu cách PostgreSQL 19 tự động đồng bộ hóa các chuỗi (sequences) trong cơ sở dữ liệu replication, giúp tránh lỗi thủ công và bảo đảm tính nhất quán khi chuyển đổi từ máy chủ sang subscriber mà không cần script bổ sung.

pgfmt 2.1: in-place formatting and pg_dump-compatible output

Phiên bản pgfmt 2.1 bổ sung hai tính năng chính: định dạng tại chỗ (--inplace/-i) cho phép ghi SQL đã format trở lại file gốc mà vẫn giữ nguyên quyền hạn, và chế độ --style pg_dump mô phỏng cách định dạng của PostgreSQL's ruleutils.c. Bản phát hành cũng cải thiện khả năng tương thích SQL/PLpgSQL, sửa lỗi mất ký tự trong string literals (như INTERVAL '2 days') và hỗ trợ cài đặt qua Homebrew.

Lập trình viên phát triển ứng dụng PostgreSQL nên đọc để tối ưu hóa việc định dạng và bảo trì mã SQL, đặc biệt là khi cần tái tạo cấu trúc chính xác của dữ liệu từ PostgreSQL bằng cách sử dụng pg_dump và khắc phục lỗi định dạng trong các script PL/pgSQL.

EDB converges analytics on Postgres to support AI agents

EDB bổ sung khả năng phân tích hội tụ cho dịch vụ cơ sở dữ liệu EDB Postgres AI, sử dụng Apache Iceberg làm lớp danh mục chia sẻ kết nối ClickHouse, WarehousePG và Spark, đồng thời cung cấp tính năng "agentic database" tự động hóa nhiệm vụ DBA định kỳ. Giải pháp này nhấn mạnh quyền kiểm soát dữ liệu tại chỗ cho doanh nghiệp, khác biệt với cách tiếp cận lakehouse của Databricks, và có mức giá theo lõi CPU ổn định hơn so với các nền tảng cloud theo mức tiêu thụ.

Lập trình viên cần đọc bài này để hiểu cách Postgres AI của EDB kết hợp với Iceberg và các công cụ phân tích khác để tạo ra một hệ sinh thái tích hợp, giúp tối ưu hóa quy trình phát triển ứng dụng AI với tính linh hoạt, kiểm soát dữ liệu và chi phí dự đoán hơn so với các giải pháp cloud tiêu thụ.

What's New in pg_clickhouse v0.3.2: Postgres 19, TLS, Regex, and Memory

Phiên bản pg_clickhouse v0.3.2 bổ sung hỗ trợ PostgreSQL 19 Beta1, các tùy chọn kết nối TLS mới (secure, min_tls_version), cải tiến xử lý regex giữa Postgres và ClickHouse, cùng tối ưu bộ nhớ cho truy vấn HTTP không đệm và tái quét join lồng. Ngoài ra còn có tùy chọn nén native protocol, cải thiện pushdown cho regexp_match() và sửa lỗi ANY() trên mảng rỗng.

Lập trình viên cần đọc bài này để cập nhật về cải tiến mới trong pg_clickhouse v0.3.2, đặc biệt là hỗ trợ PostgreSQL 19 beta1 và các tính năng TLS nâng cao, giúp tối ưu hóa kết nối và bảo mật cho ứng dụng của họ.

BranchBench Performance Update

Dolt/Doltgres addressed two major performance bottlenecks exposed by BranchBench, a database benchmark for agentic workflows. For RangeRead, the fix involved properly decomposing composite record comparisons so the query planner uses the primary key index instead of a full table scan, achieving a 653x speedup and bringing performance within 5% of Postgres. For the Simulation benchmark's evaluation query, the team improved LookupJoin cost estimation to favor HashJoins (matching Postgres's choice), cached CASE statement type evaluation, and improved hash key operations — collectively reducing the gap from 206x slower to about 18x slower than Postgres, with remaining gaps attributed to lack of parallel join/scan support.

Running pgvector in production on Amazon Aurora PostgreSQL

A comprehensive operational guide for running pgvector on Amazon Aurora PostgreSQL in production. Covers choosing between HNSW and IVFFlat indexes (or no index at all for small/partitioned datasets), configuring distance operators (cosine vs inner product), scaling to millions of vectors with quantization and partitioning, managing HNSW index churn via REINDEX CONCURRENTLY or partition-based rebuilds, capacity planning for memory-resident HNSW graphs, and observability using pg_stat_statements, CloudWatch metrics, and custom recall tracking. Includes concrete SQL examples, recommended parameter values (m=16, ef_construction=128), and a two-stage binary quantization retrieval pattern for large datasets.

Posting explains from tools (and not web browsers) – select * from depesz;

explain.depesz.com now supports a JSON response when posting PostgreSQL EXPLAIN plans via curl or other HTTP tools. By adding an Accept: application/json header to the POST request, the API returns a JSON object containing the plan ID, a shareable show URL, and a delete URL with its associated delete key — making it easy to programmatically manage posted explains without scraping HTML redirects.

PGX announces support for EOL versions of PostgreSQL

PGX has launched PGX Longevity, a commercial service offering critical security patches and data integrity bug fixes for end-of-life PostgreSQL versions (9.6 through 13, and version 14 after its final community release in November). The service is priced per client rather than per instance or core, and includes an optional SLA. It targets organizations running older PostgreSQL versions that cannot upgrade but still need ongoing maintenance support.

Issue 530

Haskell Weekly issue 530 covers the Haskell ecosystem activities report for March–May 2026 from Well-Typed (covering GHC, Cabal, HLS work), a guide on creating statically-linked Haskell executables with Nix, an introduction to the pqi library aiming to decouple Haskell PostgreSQL drivers from libpq, an introductory post on record type inference, and a deep dive into representing sheaves in Haskell using category theory. Brief announcements include apecs-0.10.0 (ECS package), Fourmolu 0.20.0.0 formatter release with GHC 9.14 support, GHC 9.12.5-rc2, and new Hpack-Dhall and Stock packages.

How to integrate OpenShift AI and PG Airman MCP Server

A deep-dive into the Data Governance Copilot architecture (Part 3), covering container-level design with SvelteKit frontend, FastAPI backend, and an agentic loop integrating OpenShift AI with the PG Airman MCP server. Explains two deployment modes: Red Hat Integrated Llama Stack versus lower-level MCP-direct using the OpenAI SDK and MCP Python library. Details how inbound LLM messages use OpenAI API format converted via Jinja tokenizer templates in vLLM, and how outbound tool calls are parsed — including a custom client-side parser needed for NVIDIA Nemotron Nano 9B due to its lack of streaming support in the native vLLM plugin. Compares Nemotron's XML-tagged TOOLCALL format against Qwen3's standard hermes parser output.

Heterogeneous Graphs in SQL/PGQ on PostgreSQL 19

PostgreSQL 19 introduces SQL/PGQ support for property graphs, and this post dives into heterogeneous graphs with multiple vertex and edge types. Using a social+work dataset (persons, companies, knows, works_at), it demonstrates how to define a multi-label property graph and write GRAPH_TABLE queries spanning different node types. Key topics include: traversing mixed-type paths (person→person→company), a workaround for PostgreSQL 19's lack of comma-separated MATCH patterns (join two GRAPH_TABLE results instead), the pitfall of anonymous edge patterns in multi-label graphs (they match all edge types via an Append plan), and the current limitation around quantified path hops ({1,3} syntax not yet supported).

All Your GUCs in a Row: enable_distinct_reordering and enable_group_by_reordering

PostgreSQL 17 and 18 introduced two planner GUCs — enable_group_by_reordering and enable_distinct_reordering — that allow the query planner to permute the keys of GROUP BY and SELECT DISTINCT operations to minimize comparison costs and avoid redundant sorts. Since column order in these clauses carries no semantic meaning, the planner can reorder keys based on cardinality and comparison cost statistics, or align them with existing sort orders to skip explicit sorts. Both default to on and are micro-optimizations that matter mainly for large multi-key operations. The primary diagnostic use case is a query that regressed after upgrading to PostgreSQL 17 or 18, where the plan shows a key order different from what was written. The recommended fix is usually improving statistics via ANALYZE rather than disabling the GUC permanently.

The AI Agent Layer: Architecture, Implementation, and the Future of Intelligent Enterprise Systems

Part 2 of a series on enterprise AI agent architecture, covering three core capabilities beyond memory: planning, tool use, and reflection. Planning patterns (ReAct, Chain-of-Thought, Tree of Thought, Plan-and-Execute) are compared, with plan-and-execute recommended as the default for regulated enterprise workflows. Tool use is examined through the lens of narrow, strongly-typed contracts backed by parameterized PostgreSQL queries — with a strong warning against letting agents generate and execute arbitrary SQL. Reflection is framed as a structured rubric-based evaluation (not a vibe check), combining deterministic database checks with critic model evaluation, and always terminating in one of four outcomes: accept, revise, escalate, or abort. The post includes concrete PostgreSQL schemas, JSON tool contracts, SQL validation via information_schema, EXPLAIN-based pre-execution guardrails, and session-level safety controls. It closes by arguing that enterprise agent design is systems engineering, not prompt engineering.

A 15-Second Health Check for Your Heroku Connect Data Pipeline

The heroku connect:diagnose CLI command provides an instant health check for Heroku Connect data pipelines syncing Salesforce with Heroku Postgres. Running it with --verbose outputs color-coded status flags (GREEN/YELLOW/RED) across two categories: connection environment checks (API version, permissions, database tier) and mapping/field validation checks (field types, schema alignment). Common warnings include outdated Salesforce API versions requiring connection recreation, unsupported binary or calculated fields that conflict with sync mechanics, and schema drift between Salesforce objects and the Postgres database. The tool replaces manual dashboard investigation and is recommended as a proactive check before database migrations or Salesforce schema changes.

Migrate MySQL to PostgreSQL: Data Types & SQL Rewrites

A practical walkthrough for migrating from MySQL to PostgreSQL, covering the full process: schema assessment, data type mapping (AUTO_INCREMENT, ENUM, unsigned integers, zero dates), SQL dialect rewrites (backticks, LIMIT syntax, IFNULL, GROUP_CONCAT, ON DUPLICATE KEY), stored procedure porting to PL/pgSQL, validation strategies, and low-downtime cutover using CDC. Includes copy-paste before/after SQL examples for common MySQL-isms and a comparison of migration tools (DBConvert, pgloader, AWS DMS).

How we migrated a live routing system using AI-assisted refactoring

Datadog's engineering team migrated their Stream Router service from a key-value FoundationDB model to a relational PostgreSQL/DuckDB architecture while serving live production traffic. The migration used Claude and Cursor in a test-driven loop: for each method, they provided the old implementation, new schema, and a failing test, letting AI generate a first pass while tests served as the correctness oracle. Key enablers were modular interfaces, a comprehensive end-to-end test suite, and a blue/green deployment setup that validated the new system against live traffic for weeks before cutover. Results were dramatic: operations that took 45 minutes now complete in ~1 second, the routing dataset shrank 40x, latencies dropped by orders of magnitude, and database costs fell 90%. The post is candid about AI limitations: it consistently produced correct but unoptimized SQL, requiring human input for batching, UNNEST tricks, and CTEs. The core lesson: the quality of your test suite is the ceiling for how much you can trust AI-generated code.

MCP For PostgreSQL: Automated Health Checks & Performance Analysis

postgres-mcp is an open-source MCP server that enables AI agents to safely troubleshoot and analyze PostgreSQL databases in production. It separates deterministic measurement (fixed diagnostic queries) from probabilistic reasoning (LLM interpretation), using restricted read-only transactions, grammar-level SQL validation via pglast, and execution time limits to prevent unsafe operations. Key capabilities include automated health checks covering indexes, buffer cache, connections, vacuum status, replication, constraints, and sequences. For workload analysis, it uses pg_stat_statements combined with hypopg to evaluate hypothetical indexes without physically creating them, employing an anytime greedy algorithm adapted from Microsoft's SQL Server tuning advisor. The post also covers practical deployment considerations including PgBouncer caveats, credential management, context window limits with large schemas, and the one-server-per-database architecture constraint.

Happiness Hint: Alarm on Checkpoint Time

PostgreSQL checkpointer is a critical but often overlooked component. Two real production incidents are detailed — one causing a 40-hour outage due to 27 million unlinked files and inode exhaustion after a week-long checkpoint stall, and another causing an 8.5-hour standby loop in CloudNativePG on Kubernetes due to disk I/O saturation and a 60-minute startup probe timeout. Key lessons: never restart a database when checkpointer is lagging, keep checkpoint_timeout at its 5-minute default, enable log_checkpoints, and set an alarm if total checkpoint time exceeds 15 minutes. A LogQL query is provided to visualize checkpoint duration trends in healthy vs. unhealthy systems.

All Your GUCs in a Row: enable_indexscan and enable_bitmapscan

A deep dive into two PostgreSQL planner GUCs — enable_indexscan and enable_bitmapscan — explaining how plain index scans and bitmap scans differ mechanically, when the planner chooses each, and how to use these toggles as diagnostic tools. Plain index scans fetch heap rows immediately per index entry (cheap for few rows, expensive for many due to random I/O), while bitmap scans first build a bitmap of matching row locations then walk the heap in physical order (efficient for larger result sets, supports multi-index BitmapAnd/BitmapOr, and uses prefetching via effective_io_concurrency). The planner selects between them based on estimated row count. Disabling enable_indexscan reveals whether a bitmap or sequential scan would be faster when an index scan underperforms; disabling enable_bitmapscan exposes alternatives when a bitmap scan goes lossy due to work_mem pressure. Both parameters are session-level diagnostic probes — not permanent configuration knobs — and the real fix lies in correcting statistics, random_page_cost, work_mem, or effective_cache_size.

Introducing pg_hardstorage: A New Community-Driven Approach to PostgreSQL Backup and Recovery

CYBERTEC has released pg_hardstorage, a new open-source PostgreSQL backup and recovery tool licensed under Apache 2.0. The project emerges from years of customer and community discussions about evolving PostgreSQL deployment models — including Kubernetes, managed cloud services, and hybrid infrastructures. Rather than claiming existing tools like pgBackRest, Barman, or WAL-G are insufficient, the announcement positions pg_hardstorage as an additional community-driven option exploring new architectural ideas. The project is hosted at pghardstorage.org with source code on GitHub, and CYBERTEC plans to publish accompanying technical articles on its design philosophy.

Some more thoughts on random_page_cost

A deep dive into PostgreSQL's random_page_cost parameter, arguing it should not be treated as a raw I/O cost measurement. The author explains that the query planner's cost model has significant gaps — it ignores memory usage, caching effects, and the concept of an 'active set' of frequently accessed data. Because of these gaps, random_page_cost effectively acts as a proxy that nudges the planner toward more localized access patterns (index scans over sequential scans), which keeps the active working set in memory. This means no profiling tool can determine the 'right' value automatically — tuning must be system-specific, guided by monitoring tools like pg_stat_statements and observing real query behavior.