Postgresql

Nguồn: GitLab Blog Tóm tắt GitLab 19.0 dự kiến phát hành vào ngày 21 tháng 5 năm 2026, bao gồm 15 breaking changes — giảm đáng kể so với con số 27 của GitLab 18.0 và 80 của GitLab 17.0. Để kiểm soát tác động, GitLab đã áp dụng quy trình phê duyệt bắt buộc trước khi bất kỳ thay đổi phá vỡ nào được đưa vào release. Một trong những thay đổi có tác động cao nhất là việc thay thế NGINX Ingress bằng Gateway API với Envoy Gateway trong GitLab Helm chart....

Nguồn: PlanetScale Blog Tóm tắt Database Traffic Control của PlanetScale được implement ở tầng database proxy — tất cả connections từ application đều đi qua proxy này trước khi đến MySQL hoặc PostgreSQL thực sự. Kiến trúc này cho phép PlanetScale intercept và kiểm soát toàn bộ queries trước khi chúng đến database, tạo ra khả năng kiểm soát real-time mà không cần thay đổi code ứng dụng. Khi một query đến proxy, nó đi qua rule evaluation pipeline gồm ba bước: rule matching (so sánh query với tất cả active rules), action determination (nếu nhiều rules match thì rule có priority cao nhất thắng), và action execution (throttle, block, hoặc kill)....

Nguồn: PlanetScale Blog Tóm tắt PlanetScale đã cải tiến tính năng tagging trong Postgres Query Insights, cho phép developers gắn metadata phong phú hơn vào các database queries để dễ dàng xác định nguồn gốc và phân tích performance. Trước đây, tagging chỉ hỗ trợ thông qua application_name PostgreSQL connection parameter — đây là static metadata, giới hạn ở một key-value pair duy nhất mỗi connection. Với enhanced tagging, hệ thống sử dụng định dạng sqlcommenter — một open-source specification do Google phát triển....

Nguồn: PlanetScale Blog Tóm tắt Graceful degradation là khả năng hệ thống tiếp tục hoạt động ở mức giảm sút khi một phần của nó gặp sự cố hoặc bị quá tải. Trong ngữ cảnh Postgres, điều này có nghĩa là ứng dụng vẫn có thể phục vụ người dùng ngay cả khi database đang bị stress hoặc không hoàn toàn sẵn sàng. Caching là hình thức phổ biến nhất của graceful degradation....

Nguồn: PlanetScale Blog Tóm tắt Khi theo dõi một Postgres server và thấy memory usage lên đến 70-90% RAM, phản ứng đầu tiên thường là lo lắng và muốn điều tra. Thực tế, trong hầu hết các trường hợp, memory usage cao trong Postgres không phải là vấn đề — đó là dấu hiệu Postgres đang hoạt động hiệu quả. Postgres sử dụng bộ nhớ theo nhiều cách khác nhau. Shared buffers là cache in-memory cho data pages: khi Postgres đọc dữ liệu từ disk, các page được lưu vào shared buffers để các lần đọc sau phục vụ từ RAM thay vì disk....

Nguồn: PlanetScale Blog Tóm tắt Kiểm soát luồng traffic vào database Postgres là một trong những quyết định kiến trúc quan trọng nhất khi xây dựng và mở rộng ứng dụng. PlanetScale đã tổng hợp các pattern phổ biến nhất bao gồm connection pooling, read replicas với read/write splitting, query routing, circuit breakers và rate limiting ở tầng database. Connection pooling là kỹ thuật cơ bản nhất: Postgres sử dụng mô hình process-per-connection, tức mỗi client kết nối sẽ tạo ra một backend process mới, tiêu tốn bộ nhớ và CPU đáng kể....

Nguồn: PlanetScale Blog Tóm tắt Postgres sử dụng mô hình process-based: mỗi client connection spawns một backend process mới, tiêu tốn 5-10MB RAM, CPU cho context switching, và file descriptors. Khi connection count tăng, memory pressure và context switching overhead khiến query throughput giảm và latency tăng. max_connections mặc định là 100 — đây là ngưỡng giới hạn cứng của Postgres. PgBouncer (ra mắt 2007) là connection pooler phổ biến nhất giải quyết vấn đề này: clients kết nối vào PgBouncer thay vì trực tiếp vào Postgres, và PgBouncer duy trì một pool nhỏ các kết nối thực sự đến database, multiplexing requests từ nhiều clients qua số lượng connections ít hơn....

Nguồn: PlanetScale Blog Tóm tắt Ứng dụng video conferencing có yêu cầu dữ liệu phức tạp: signaling real-time, tracking participants, quản lý rooms và sessions, lưu meeting metadata, chat và file sharing. Bài viết hướng dẫn cách model và implement data layer cho ứng dụng video conferencing sử dụng Postgres, bao gồm schema design và các kỹ thuật real-time. Core data model bao gồm ba entities chính: Rooms (có thể là scheduled meeting, instant meeting, hoặc persistent room với join_code unique), Participants (track joined_at, left_at, is_host, audio_enabled, video_enabled), và Sessions (một room persistent có thể có nhiều sessions theo thời gian, mỗi session có recording_url)....