PostgreSQL 19 Beta 2؛ قبل از GA چه چیزهایی را روی دیتابیس واقعی تست کنیم؟

PostgreSQL 19 Beta 2 در 16 ژوئیه 2026 منتشر شد. تیم PostgreSQL صریحاً توصیه می کند Beta را روی workloadهای واقعی آزمایش کنید، اما آن را برای Production مناسب نمی داند. ارزش این مرحله دقیقاً همین است: قبل از GA، Query Plan، Driver، Extension، Logical Decoding، Temporal SQL، SQL/PGQ و رفتارهای عملیاتی را روی داده ای شبیه محیط واقعی بسنجید و Regressionها را زود پیدا کنید.

Beta 2 دقیقاً چه جایگاهی در چرخه PostgreSQL 19 دارد؟

در دوره Beta، Feature set تا حد زیادی منجمد شده تا جامعه روی Bug، compatibility و performance تمرکز کند، اما رفتار و جزئیات API هنوز می تواند تغییر کند. بنابراین تصمیم درست این نیست که Production را زودتر به 19 ببرید؛ تصمیم درست این است که Test Suite و workload واقعی را علیه Beta اجرا کنید تا قبل از RC و GA مشکل قابل بازتولید داشته باشید.

برای تیم Backend، Beta testing یک فرصت دوطرفه است. شما ریسک مهاجرت خودتان را کم می کنید و اگر Regression عمومی پیدا شود، زمان کافی برای گزارش و Fix قبل از انتشار نهایی وجود دارد. Test ارزشمند باید از Dataset و Query واقعی الهام بگیرد، نه فقط اجرای چند SELECT ساده روی دیتابیس خالی.

چه تغییراتی در Beta 2 ارزش تست مستقیم دارند؟

اعلامیه رسمی Beta 2 به مجموعه ای از Fixها اشاره می کند: چند اصلاح برای FOR PORTION OF در Temporal table syntax، اصلاحات SQL/PGQ، Race Condition در فعال سازی Logical Decoding، محاسبه multixact-age در Autovacuum، رفتار imported statistics در postgres_fdw و چند ابزار مدیریتی. این لیست بهترین سرنخ برای ساخت Test Caseهای هدفمند است.

اگر هیچ کدام از این قابلیت ها را مستقیم استفاده نمی کنید، باز هم Query Planner، Driver، Extension و عملیات Backup/Restore باید تست شوند. Major Version مجموعه بزرگی از تغییرات دارد و Beta2 فقط Delta نسبت به Beta1 را برجسته می کند؛ Release Notes کامل PostgreSQL 19 مرجع Featureهای اصلی است.

محیط تست را چگونه به Production نزدیک کنیم؟

بهترین Dataset نسخه ناشناس شده ای از داده واقعی است، با همان Distribution، cardinality و حجم نسبی. Database کوچک Development معمولاً skew داده، index bloat، query planهای پیچیده و lock pattern را نشان نمی دهد. اگر داده Production قابل کپی نیست، synthetic data باید ویژگی های آماری آن را بازسازی کند، نه فقط تعداد row را.

Collation، Locale، Extension، configurationهای مهم و parameterهایی مثل work_mem، shared_buffers و autovacuum setting را تا حد ممکن مشابه نگه دارید. تفاوت محیط می تواند باعث شود نتیجه Benchmark به نسخه PostgreSQL نسبت داده شود در حالی که علت واقعی Configuration است.

pg_upgrade یا pg_dump/pg_restore؛ تمرین مهاجرت

PostgreSQL برای رفتن به Beta 2 روشی مشابه Major Upgrade لازم می داند و pg_upgrade یا dump/restore را به عنوان مسیرهای شناخته شده مطرح می کند. حتی اگر امروز قصد Production migration ندارید، همین حالا زمان Upgrade rehearsal را اندازه بگیرید. Backup قابل Restore با Backup صرفاً «موفق» تفاوت دارد.

در rehearsal، زمان downtime بالقوه، فضای دیسک، extension compatibility و مرحله rollback را ثبت کنید. اگر pg_upgrade سریع تر است اما یک Extension مانع می شود، این blocker باید ماه ها قبل از GA پیدا شود. اگر dump/restore انتخاب شماست، throughput و مدت restore روی حجم واقعی را اندازه بگیرید.

Query Plan Regression را چگونه شکار کنیم؟

از pg_stat_statements یا Observability موجود، مجموعه Queryهای پرتکرار و گران را استخراج کنید. برای هر Query روی نسخه فعلی و PostgreSQL 19، EXPLAIN ANALYZE، buffers، rows estimate و زمان اجرا را ثبت کنید. مقایسه متن Plan به تنهایی کافی نیست؛ نتیجه و هزینه واقعی مهم است.

Queryهای دارای skew، چند Join، Partition، Expression Index و window function را جلوتر بگذارید. یک Regression ده درصدی روی Query که در هر درخواست اجرا می شود می تواند مهم تر از دوبرابر سریع ترشدن گزارش هفتگی باشد. Performance impact را با وزن usage بسنجید.

FOR PORTION OF و Temporal SQL؛ Edge Caseها را جدی بگیرید

Beta 2 چند Fix مستقیم برای FOR PORTION OF دارد. اگر قصد استفاده از قابلیت های Temporal را دارید، update/delete روی intervalهای هم پوشان، مرز شروع/پایان، range خالی، constraint و transaction concurrent را تست کنید. Happy path نمی تواند درستی semantics زمانی را ثابت کند.

برای هر Case، Result set و state نهایی table را صریح ذخیره کنید. چون Beta ممکن است تا GA تغییر کند، Testها را version کنید و روی RC دوباره اجرا کنید. این Test Suite بعدها نیز هنگام upgrade بعدی یک دارایی پایدار خواهد بود.

SQL/PGQ و Property Graph؛ فقط Demo مسیر کوتاه کافی نیست

PostgreSQL 19 قابلیت های SQL/PGQ را برای Queryهای graph-oriented جلو می برد و Beta 2 چند Fix مرتبط دارد. اگر use case شما relationship traversal است، Dataset باید cycle، node/edge گمشده، pathهای طولانی و cardinality متفاوت داشته باشد. Graph query روی ده node تقریباً هیچ چیز درباره رفتار workload واقعی نمی گوید.

همچنین تصمیم کنید چرا Graph را داخل PostgreSQL می خواهید. اگر داده اصلی relational است و چند traversal محدود دارید، یکپارچگی می تواند مزیت باشد. اگر workload عمدتاً graph traversal پیچیده است، باید آن را در برابر Graph Database تخصصی نیز Benchmark کنید. Feature جدید نباید architecture decision را از پیش تعیین کند.

Logical Decoding و CDC؛ از Event رسیدن فراتر بروید

Beta 2 یک Race Condition در فعال سازی Logical Decoding را اصلاح کرده است. تیم هایی که CDC، Debezium، logical replication یا consumer سفارشی دارند باید lifecycle slot، restart database، failover و lag را آزمایش کنند. فقط دیدن اولین Event در Kafka یا downstream اثبات سازگاری نیست.

Ordering، duplicate handling، schema change، transaction بزرگ و recovery بعد از قطع consumer را وارد Test Matrix کنید. اگر downstream exactly-once فرض می کند اما transport at-least-once است، Upgrade ممکن است با یک Failure این فرض پنهان را آشکار کند.

Autovacuum و تست طولانی مدت

یکی از Fixهای Beta 2 به محاسبه multixact-age در score مربوط به Autovacuum اشاره دارد. این دسته رفتار با Benchmark پنج دقیقه ای دیده نمی شود. Soak Test چندساعته یا چندروزه با update/delete واقعی اجرا کنید و dead tuples، transaction age، vacuum activity، lock و disk growth را مانیتور کنید.

Operational regression اغلب دیرتر از query regression ظاهر می شود. Database ممکن است روز اول سریع باشد ولی بعد از چند روز bloat یا checkpoint behavior نامناسب ایجاد کند. برای major upgrade، تست طولانی یک جزء اصلی است نه مرحله اختیاری.

Extension، Driver و ORM؛ زنجیره سازگاری واقعی

Extensionهای Native ممکن است به API یا ساختار داخلی PostgreSQL حساس باشند. فهرست Extensionهای Production را استخراج کنید و برای هرکدام Release یا support statement سازگار با 19 پیدا کنید. Extension بدون نسخه سازگار می تواند کل برنامه migration را متوقف کند، حتی اگر core database عالی کار کند.

Driver و ORM را نیز روی integration test واقعی بسنجید. connection pool، prepared statement، type mapping، migration tool و transaction behavior مهم اند. یک CI job آزمایشی با PostgreSQL 19 Beta بسازید تا ناسازگاری زود دیده شود؛ تا زمان GA می تواند non-blocking باشد.

postgres_fdw و ابزارهای مدیریتی را فراموش نکنید

Beta 2 اصلاحی برای imported foreign statistics در postgres_fdw دارد و همچنین Fixهایی برای ابزارهایی مانند vacuumdb و pg_createsubscriber ذکر می کند. تیم هایی که automation مدیریتی دارند باید Commandهای روزمره خود را در Test Suite بیاورند. Migration فقط Query اپلیکیشن نیست؛ Runbook DBA هم باید کار کند.

Backup، analyze، vacuum، subscriber creation و monitoring queryها را روی Beta اجرا کنید. ابزار یا script قدیمی ممکن است به خروجی متنی خاص وابسته باشد و تغییر کوچک format را error تلقی کند. Automation contract باید مثل API contract تست شود.

Test Matrix پیشنهادی قبل از GA

به جای یک checklist پراکنده، Testها را در پنج محور Correctness، Performance، Compatibility، Operations و Upgrade دسته بندی کنید. هر محور Owner، Dataset و معیار pass/fail داشته باشد. این ساختار باعث می شود Release Candidate همان ماتریس را دوباره اجرا کند و Delta قابل مقایسه باشد.

نتیجه «همه چیز خوب بود» ارزش کمی دارد. نتیجه خوب شامل Queryهای سنجیده شده، نسخه Driver/Extension، duration upgrade، Regressionهای مشاهده شده و issueهای باز است. Evidence را نگه دارید تا تصمیم GA بر اساس حافظه تیم نباشد.

چه زمانی بعد از GA به Production برویم؟

GA به معنی اینکه همان روز همه workloadها باید upgrade شوند نیست. ابتدا Release Notes نهایی را با Beta test report مقایسه کنید، سپس Extension و Driver support را تأیید و RC/GA Test Matrix را تکرار کنید. اگر blocker اصلی حل نشده، چند هفته صبر کردن ممکن است ریسک کمتری از مهاجرت فوری داشته باشد.

از طرف دیگر، تعویق بدون تاریخ نیز strategy نیست. Lifecycle نسخه فعلی، نیاز Featureهای 19 و operational capacity را وارد تصمیم کنید. Migration window را برنامه ریزی و rehearsal را با نسخه نهایی تکرار کنید.

چطور Bug یا Regression خوب گزارش کنیم؟

اگر Beta مشکلی نشان داد، حداقل نسخه دقیق PostgreSQL، OS، configuration مرتبط، SQL قابل بازتولید و expected/actual behavior را ثبت کنید. برای performance regression، Plan هر دو نسخه و Dataset حداقلی کمک بزرگی است. گزارش مبهم «نسخه 19 کندتر است» قابل اقدام نیست.

قبل از کمینه سازی، Evidence محیط واقعی را حفظ کنید؛ سپس reproduction را کوچک کنید. هدف ساختن Test Case ای است که توسعه دهنده PostgreSQL بدون دسترسی به سیستم شما بتواند Failure را ببیند. این مهارت برای Bugهای داخلی تیم نیز ارزش دارد.

Baseline نسخه فعلی را قبل از Beta ثبت کنید

هر مقایسه ای بدون Baseline قابل اعتماد، به برداشت شخصی تبدیل می شود. پیش از ساخت محیط PostgreSQL 19، نسخه فعلی Production را با workload نماینده اندازه بگیرید: throughput، p50/p95/p99 query latency، buffer hit ratio، lock wait، checkpoint، WAL volume، vacuum duration و storage growth. برای Queryهای کلیدی Plan و Execution Statistics را ذخیره کنید. این Baseline باید با همان Dataset و Configurationی که برای Beta استفاده می کنید قابل تکرار باشد.

اگر production traffic قابل replay مستقیم نیست، یک workload profile بسازید: نسبت read/write، query mix، تعداد connection، transaction duration و burst pattern را مشخص کنید. Benchmark مصنوعی که فقط SELECT ساده می زند ممکن است Beta را عالی نشان دهد اما bottleneck واقعی شما در write contention یا long transaction پنهان بماند.

Rollback و fallback را قبل از Upgrade نهایی طراحی کنید

Major Upgrade به PostgreSQL فقط مسئله بالا آمدن Cluster جدید نیست. باید بدانید اگر چند ساعت بعد از Cutover مشکل جدی دیدید، داده نوشته شده در نسخه جدید چگونه مدیریت می شود. بازگشت ساده به Snapshot قدیمی می تواند داده های پس از Cutover را از دست بدهد. قبل از GA درباره strategy مشخص برای dual-write، logical replication، maintenance window یا accepted data-loss window تصمیم بگیرید.

در rehearsal، Trigger rollback را نیز تعریف کنید: چه Latency، Error، replication lag یا correctness issue باعث توقف Migration می شود و چه کسی تصمیم نهایی را می گیرد. وقتی این معیارها قبل از Incident نوشته شوند، تیم در لحظه فشار به جای مذاکره از Runbook پیروی می کند.

جلسه Go/No-Go را با Evidence برگزار کنید

پیش از مهاجرت نسخه نهایی، یک Go/No-Go کوتاه با DBA، Backend، Platform و صاحب محصول برگزار کنید. ورودی جلسه باید Test Report باشد: Regressionهای حل نشده، وضعیت Extensionها، زمان Upgrade rehearsal، ظرفیت Rollback و اثر احتمالی downtime. «نسخه جدید منتشر شده» دلیل کافی برای Go نیست؛ همان طور که «Beta بود و ما نترسیدیم» نیز Evidence محسوب نمی شود.

شرط No-Go را از قبل تعیین کنید؛ مثلاً Extension حیاتی بدون پشتیبانی، correctness regression یا recovery plan آزمایش نشده. این شفافیت کمک می کند هیجان Featureهای PostgreSQL 19، محدودیت های عملیاتی را پنهان نکند و تصمیم نهایی قابل Audit باقی بماند.

پس از Go نیز نتیجه را به عنوان ADR یا Change Record نگه دارید تا تیم بداند کدام فرض ها، Metricها و نسخه Dependencyها مبنای تصمیم بوده اند. این سند در Upgrade بعدی نقطه شروع بسیار بهتری از بازسازی حافظه افراد است.

نمونه یا الگوی عملی

pg_dump --format=custom --file=app.dump appdb
createdb appdb19
pg_restore --dbname=appdb19 app.dump
# Restore را فقط در محیط تست PostgreSQL 19 اجرا کنید.

این نمونه مسیر dump/restore را برای rehearsal نشان می دهد. در دیتابیس بزرگ باید parallelism، زمان downtime، فضای دیسک و recovery plan را متناسب با محیط خودتان اندازه بگیرید.

پرسش های متداول

آیا PostgreSQL 19 Beta 2 برای Production مناسب است؟

خیر. پروژه PostgreSQL صریحاً استفاده از Beta در Production را توصیه نمی کند.

Beta 2 چه زمانی منتشر شد؟

در 16 ژوئیه 2026 منتشر شد.

برای تست Upgrade از چه روش هایی می توان استفاده کرد؟

روش های Major Upgrade مانند pg_upgrade یا pg_dump/pg_restore را روی محیط جداگانه تمرین کنید.

آیا Featureهای Beta تا GA می توانند تغییر کنند؟

بله. جزئیات behavior و API در دوره Beta هنوز ممکن است تغییر کند.

مهم ترین تست برای اپلیکیشن عادی چیست؟

Replay queryهای واقعی، سازگاری Driver/ORM/Extension و رفتار عملیاتی مانند Vacuum و Backup.

چه زمانی Test Matrix را دوباره اجرا کنیم؟

روی Release Candidate و سپس نسخه GA همان Test Matrix را تکرار کنید.

منابع رسمی

• اعلامیه رسمی PostgreSQL 19 Beta 2 — تاریخ انتشار، Fixهای Beta2، روش Upgrade و هشدار Production
• راهنمای رسمی PostgreSQL Beta Testing — هدف Beta/RC و روش مشارکت در تست
• Release Notes رسمی PostgreSQL 19 — مرجع Featureها و Migration issueهای نسخه 19