#olap

Agentic kill switch is a database problem. So we built Redpanda SQL

Redpanda SQL cho phép truy vấn dữ liệu streaming trực tiếp và bảng Iceberg lịch sử trong cùng một câu lệnh SQL, hiện đã khả dụng trên AWS và Google Cloud.

Lập trình viên cần đọc bài này để khám phá cách Redpanda SQL hợp nhất truy vấn thời gian thực với dữ liệu lịch sử từ Iceberg trong cùng một câu SQL, giúp tối ưu hóa hiệu suất và đơn giản hóa việc xử lý dữ liệu stream và batch trên các nền tảng cloud AWS và GCP.

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ồ.

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ụ.

Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD

pgrust 0.2 cải thiện hiệu suất truy vấn phân tích lên 300 lần so với Postgres nhờ ba tối ưu hóa: batching (xử lý 1024 phần tử/lần thay vì từng dòng), operator fusion (kết hợp scan và aggregation thành một node) và SIMD (sử dụng ARM NEON để xử lý 8 float/chu kỳ). Các cải tiến này nâng tốc độ từ 1.3s xuống còn 135ms, góp phần vào hiệu suất tổng thể vượt trội so với ClickHouse.

Nếu bạn đang tìm cách tối ưu hóa hiệu suất cho các ứng dụng phân tích dữ liệu trên PostgreSQL, bài viết này sẽ giúp bạn hiểu rõ cách áp dụng batching, operator fusion và SIMD trong Rust để đạt được tăng tốc 300 lần so với phiên bản gốc, giúp bạn áp dụng các kỹ thuật tiên tiến ngay trong dự án của mình.

Why Coinbase and Pinterest Chose StarRocks: Lakehouse-Native Design and Fast Joins at Terabyte Scale

StarRocks được các kỹ sư dữ liệu tại Coinbase, Pinterest và Fresha ưa chuộng nhờ hiệu suất OLAP cao, hỗ trợ phân tích tức thì trên dữ liệu terabyte nhờ tính năng join phân tán nhanh (colocated join groups) và kiến trúc hybrid hot/cold. Các công ty này ghi nhận cải thiện đáng kể về độ trễ truy vấn (giảm 50% tại Pinterest, đạt dưới 100ms tại Fresha) và tiết kiệm tài nguyên, mặc dù StarRocks đòi hỏi mô hình dữ liệu cẩn thận và có cộng đồng nhỏ hơn so với ClickHouse.

Nếu bạn đang xây dựng hệ thống phân tích lớn trên dữ liệu terabyte, hiểu cách StarRocks tối ưu hóa join phân tán bằng cách đồng bộ hóa nhóm join (colocated) sẽ giúp bạn tránh những rắc rối về latency và chi phí hạ tầng khi so sánh với các giải pháp truyền thống.

DuckDB Ecosystem Newsletter : July 2026

Tháng 7/2026, bản tin hệ sinh thái DuckDB giới thiệu giải pháp phân tích di động kết hợp R2 + DuckLake, lý do PostHog chuyển từ ClickHouse sang DuckDB, sự kiện DuckCon #7 cùng các bản phát hành 1.5.4 và 1.4.5, cùng phiên bản SedonaDB chạy trên WASM cho SQL không gian trong trình duyệt.

Lập trình viên cần đọc để khám phá cách DuckDB tích hợp với các công cụ analytics hiện đại như PostHog và SedonaDB, giúp tối ưu hóa hiệu suất cho ứng dụng của mình bằng kiến trúc portability và tính mở rộng cao.

Running DuckDB as a MySQL 9.7 storage engine

An experimental MySQL 9.7 build called ducksdb-mysql-engine integrates DuckDB as a pluggable storage engine, allowing tables marked ENGINE=DuckDB to offload analytical queries to DuckDB's columnar engine while keeping the same MySQL connection and data. A custom pushdown_select hook (handlerton::pushdown_select) translates qualifying SQL to DuckDB SQL transparently, falling back to the normal row path when needed. TPC-H benchmarks at scale factor 10 show InnoDB timing out on 6 of 22 queries and taking 1317 seconds on the rest, while the DuckDB engine completes all 22 in ~15 seconds. At SF100 (600M rows), the engine remains correct on all 22 queries and stays close to native DuckDB performance, outperforming MariaDB's DuckDB integration on several heavy joins and loading data ~4x faster. The project is open source under GPLv2 and explicitly experimental.

Six Things Enterprise Architects Get Wrong About the Operational–Analytical Chasm — and How to Close the Agentic Loop

Enterprise architects have long treated the operational-analytical divide as a design principle, but it was always just a hardware-era workaround. With AI agents that must observe, reason, and act on live data, the old one-way ETL pipeline becomes a critical bottleneck. Six common architectural mistakes are examined: treating the OLTP/OLAP split as immutable law, viewing pipelines as architecture rather than overhead, misunderstanding freshness and consistency contracts, fragmenting governance across two estates, treating mirrored systems as set-and-forget, and underestimating the shift from analytics to agentic workloads. Snowflake Postgres with data mirroring is presented as a concrete implementation that collapses this chasm, enabling a bidirectional observe-reason-act loop for AI agents. Practical steps include auditing CDC pipelines, separating first-party from third-party data, setting freshness per workload, and designing the agentic write-back path from the start.

Postgres vs Oracle

A technical comparison of Postgres and Oracle Database covering licensing costs, extension ecosystems, SQL dialect differences, HA architecture, and partitioning maturity. Both databases share the same OLTP ceiling for analytical workloads — once tables grow large, aggregation queries degrade performance. The recommended architectural pattern for both is CDC-based streaming to a columnar OLAP layer (ClickHouse/Tinybird), keeping the operational database for transactions. Includes a practical Oracle-to-Postgres SQL translation table and notes on PL/SQL migration challenges.

Real-Time Analytics: Boost your business with instant data

Bài viết giới thiệu về real-time analytics (phân tích thời gian thực) qua 5 yếu tố cốt lõi (độ tươi mới của dữ liệu, độ trễ truy vấn thấp, độ phức tạp truy vấn cao, khả năng truy vấn đồng thời, lưu trữ dữ liệu lâu dài), phân biệt với batch và streaming analytics, cùng các trường hợp sử dụng phổ biến như cá nhân hóa, phát hiện gian lận, dashboard người dùng, quản lý hàng tồn kho. Bài viết cũng đề cập thách thức (công cụ, quy mô, chi phí, cộng tác nhóm) và kiến trúc 3 lớp (data streaming, real-time databases, API layers). Ngoài ra, Tinybird được giới thiệu như một nền tảng quản lý real-time analytics dựa trên ClickHouse, hỗ trợ ingest từ Kafka/S3/HTTP Events API, pipeline biến đổi SQL và xuất API có độ trễ thấp.

Lập trình viên nên đọc bài này để hiểu cách xây dựng và tối ưu hệ thống phân tích dữ liệu thực thời từ cơ sở hạ tầng đến giải pháp API, giúp họ thiết kế giải pháp hiệu quả hơn cho ứng dụng của mình.

Bridge Queries in Redpanda SQL

Redpanda SQL introduces bridge queries, a feature that lets you query live Redpanda topic data and historical Iceberg table data together through a single virtual SQL table. This eliminates the classic streaming-to-lakehouse tradeoff between data freshness and Parquet file quality. Previously, frequent flushes to Iceberg were needed for low-latency analytics, resulting in thousands of tiny Parquet files, poor compression, high S3 costs, and constant compaction overhead. With bridge queries, the topic itself serves the freshness gap at query time, so Iceberg flushes can happen on a longer cadence (hours instead of seconds/minutes), producing larger, analytics-optimized Parquet files. Configuration involves raising the iceberg lag target and optionally the flush size threshold. The result is lower query latency, reduced S3 costs, and no need for a compaction service.