Database Labdon
797 subscribers
33 photos
2 videos
1 file
727 links
🕸 Database Academy

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Redis is Fast - I'll Cache in Postgres

🟢 خلاصه مقاله:
** این مقاله مقایسه‌ای بین استفاده از Postgres و Redis برای کارهای کش ساده ارائه می‌کند و نتیجه می‌گیرد که هرچند Redis از نظر سرعت خام برتر است، در بسیاری از سناریوها این برتری آن‌قدر نیست که اضافه‌کردن یک سیستم جداگانه را توجیه کند. اگر داده‌های پرتکرار در حافظه Postgres جا شوند و با یک جدول کلید-مقدار ساده (به‌همراه expires_at و ایندکس مناسب)، prepared statements و connection pooling کار کنید، تأخیر به‌حد کافی پایین و پایدار خواهد بود. زمانی Redis منطقی است که به تأخیر بسیار کم و QPS بسیار بالا نیاز دارید، کش مشترک بین سرویس‌ها می‌خواهید، یا به قابلیت‌های خاص آن مثل data structures، pub/sub و eviction policies نیاز دارید. در غیر این صورت، سادگی عملیاتی، هزینه کمتر و کاهش نقاط خرابی با استفاده از Postgres ارزشمندتر است؛ و در صورت آشکار شدن گلوگاه عملکردی، می‌توان بعداً Redis را پشت یک رابط مناسب اضافه و به‌تدریج مهاجرت کرد.

#Redis #Postgres #Caching #Performance #Databases #Architecture #DevOps #Scalability

🟣لینک مقاله:
https://postgresweekly.com/link/174758/web


👑 @Database_Academy
🔵 عنوان مقاله
postgres-contrib.org

🟢 خلاصه مقاله:
postgres-contrib.org یک وبلاگ با رویکرد گردآوری هفتگی (اغلب هفتگی) است که مهم‌ترین مشارکت‌ها و تغییرات در پروژه Postgres را به‌صورت خلاصه و قابل‌خواندن ارائه می‌کند. این گردآورها حوزه‌هایی مانند بهبودهای هسته، افزونه‌ها، کارایی، رفع باگ، به‌روزرسانی مستندات و ابزارهای پیرامونی را پوشش می‌دهند و معمولاً در صورت امکان لینک‌هایی برای پیگیری کد یا بحث‌های مرتبط ارائه می‌شود. این رویکرد به توسعه‌دهندگان، DBAها و مشارکت‌کنندگان کمک می‌کند بدون جست‌وجوی پراکنده، از روندها و تغییرات مهم باخبر شوند، برای ارتقاها برنامه‌ریزی کنند و فرصت‌های مشارکت را ببینند. هدف، تکمیل یادداشت‌های رسمی انتشار با یک چکیده جامعه‌محور و منظم از فعالیت‌های جاری در اکوسیستم PostgreSQL است.

#Postgres #PostgreSQL #OpenSource #Database #Community #Contributions #WeeklyDigest

🟣لینک مقاله:
https://postgresweekly.com/link/176675/web


👑 @Database_Academy
🔵 عنوان مقاله
"You Don't Need Kafka, Just Use Postgres" Considered Harmful

🟢 خلاصه مقاله:
** گونار مورلینگ به ادعای «You Don’t Need Kafka, Just Use Postgres» پاسخ می‌دهد و می‌گوید این توصیه اگر به‌صورت کلی پذیرفته شود گمراه‌کننده و مضر است. به‌زعم او، جایگزین‌کردن یک لاگ توزیع‌شده با یک پایگاه‌داده رابطه‌ای، تفاوت اساسی میان «event streaming» و «OLTP» را نادیده می‌گیرد: Kafka تضمین‌هایی مثل نگهداری رویدادها، ترتیب‌پذیری، قابلیت replay، fan-out مستقل و مدیریت backpressure ارائه می‌کند که Postgres ذاتاً برای آن ساخته نشده است. البته در مقیاس‌های کوچک و سناریوهای ساده، انتخاب Postgres می‌تواند کافی و ساده‌تر باشد؛ اما با رشد سیستم و نیاز به جداسازی سرویس‌ها و replay تاریخی، محدودیت‌ها آشکار می‌شوند. مورلینگ الگوهایی مثل outbox و CDC (با ابزارهایی مانند Debezium) را برای پیوندزدن دنیای تراکنشی Postgres با جریان رویداد در Kafka توصیه می‌کند. جمع‌بندی او: نسخه‌های کلی «فقط از X استفاده کنید» خطرناک‌اند؛ نیازها را دقیق تحلیل کنید و براساس مبادله‌های واقعی ابزار مناسب یا ترکیب ابزارها را برگزینید.

#Kafka #Postgres #EventStreaming #CDC #Debezium #SoftwareArchitecture #Scalability

🟣لینک مقاله:
https://postgresweekly.com/link/176683/web


👑 @Database_Academy
🔵 عنوان مقاله
Hybrid Search in Postgres: The Missing Manual

🟢 خلاصه مقاله:
** این مقاله راهنمایی عملی برای جست‌وجوی هیبریدی در Postgres ارائه می‌کند و نشان می‌دهد چرا ترکیب امتیازدهی BM25 با ParadeDB و جست‌وجوی شباهت برداری با pgvector از جست‌وجوی متنی داخلی Postgres در رده‌بندی مرتبط‌تر بهتر عمل می‌کند. BM25 پوشش دقیق کلیدواژه و عبارت را فراهم می‌کند، در حالی‌که بردارها معنای پرسش را با واژه‌های هم‌معنی و بازنویسی‌ها درمی‌یابند. الگوی معمول یا انتخاب نامزدها با BM25 و بازمرتب‌سازی با شباهت برداری است، یا ادغام نتایج هر دو با وزن‌دهی نرمال‌شده. همه این‌ها داخل یک پایگاه Postgres انجام می‌شود—با ایندکس‌های متن و بردار—و بدون نیاز به موتورهای خارجی، در سناریوهایی مثل جست‌وجوی محصول، مستندات و Q&A به بهبود محسوس ربط نتایج نسبت به FTS بومی می‌انجامد.

#Postgres #HybridSearch #BM25 #pgvector #VectorSearch #FullTextSearch #ParadeDB #RelevanceRanking

🟣لینک مقاله:
https://postgresweekly.com/link/176019/web


👑 @Database_Academy
🔵 عنوان مقاله
Introducing pg_lake: Integrate Your Data Lakehouse with Postgres

🟢 خلاصه مقاله:
pg_lake مجموعه‌ای از افزونه‌ها برای Postgres است که اتصال مستقیم به درياچه‌داده و Lakehouse را ممکن می‌کند: پشتیبانی جامع از Iceberg و دسترسی به فایل‌های Parquet، CSV و JSON بدون جابه‌جایی داده یا خروج از محیط Postgres. این راهکار با ادغام شفاف DuckDB در موتور پرس‌وجوی Postgres، اجرای برداری و ستونی سریع را برای اسکن‌ها و تجمع‌های سنگین فراهم می‌کند، در حالی‌که همچنان با SQL آشنا کار می‌کنید. با pg_lake می‌توانید داده‌های دریاچه را مثل جدول‌های عادی بخوانید، آن‌ها را با جداول عملیاتی Postgres جوین بزنید و نیاز به ETL اضافی را کاهش دهید. پشتیبانی از Iceberg برای سناریوهایی مثل پارتیشن‌بندی و تکامل طرحواره مناسب است و مسیرهایی مانند تحلیل‌های موردی، کوئری‌های فدره، و مهاجرت تدریجی به Lakehouse را ساده می‌کند. کد و مستندات آن در GitHub در دسترس است.

#pg_lake #Postgres #DataLakehouse #Iceberg #DuckDB #Parquet #SQL #OpenSource

🟣لینک مقاله:
https://postgresweekly.com/link/176670/web


👑 @Database_Academy
🔵 عنوان مقاله
Don't Give Postgres Too Much Memory

🟢 خلاصه مقاله:
خلاصه‌ای از دیدگاه Tomas این است که در Postgres همیشه «حافظه بیشتر=بهتر» نیست. بالا بردن بی‌محابای maintenance_work_mem و work_mem می‌تواند اندازه مجموعه کاری را بزرگ‌تر از CPU cache کند و با افزایش cache miss، سرعت مرتب‌سازی و هش را کم کند. علاوه بر آن، تخصیص‌های بزرگ، بار مدیریت حافظه روی OS را زیاد می‌کند و در بار همزمان، چون work_mem به‌ازای هر نود و هر کوئری اعمال می‌شود، مصرف واقعی حافظه چندبرابر شده و افت کارایی رخ می‌دهد. نتیجه عملی: مقادیر را معقول و مرحله‌ای تنظیم کنید، با سناریوهای واقعی بنچمارک بگیرید، در صورت نیاز به‌صورت موردی با SET مقدار work_mem را برای عملیات سنگین بالا ببرید، و به تعامل CPU cache و مدیریت حافظه OS توجه کنید؛ همیشه مقدار بیشتر سریع‌تر نیست.

#Postgres #PostgreSQL #DatabasePerformance #work_mem #maintenance_work_mem #CPUCaches #OSMemory

🟣لینک مقاله:
https://postgresweekly.com/link/176669/web


👑 @Database_Academy
🔵 عنوان مقاله
pg_timetable 6.1 Released: Advanced Job Scheduling Extension

🟢 خلاصه مقاله:
نسخه 6.1 از pg_timetable منتشر شد؛ یک افزونه مستقل و پخته برای زمان‌بندی کارها که کاملاً داخل پایگاه داده اجرا می‌شود. این ابزار اجازه می‌دهد در خود Postgres، فرمان‌ها و کوئری‌ها، برنامه‌های سیستمی و عملیات داخلی را زمان‌بندی کنید و وظایف را به‌صورت زنجیره‌ای به هم متصل کنید تا گردش‌کارهای چندمرحله‌ای بسازید. اجرای زمان‌بندی داخل پایگاه داده، استقرار را ساده می‌کند، با سیاست‌های دسترسی و پشتیبان‌گیری هماهنگ است و برای نگه‌داری دوره‌ای، ETL، گزارش‌گیری، کنترل کیفیت داده و پشتیبان/خروجی گرفتن بسیار مناسب است. نسخه جدید بر بلوغ و آمادگی تولیدی این راهکار تأکید دارد و گزینه‌ای عملی برای خودکارسازی مبتنی بر پایگاه داده بدون نیاز به سرویس‌های خارجی اضافی ارائه می‌کند.

#pg_timetable #Postgres #JobScheduler #DatabaseAutomation #ETL #DevOps #OpenSource #DataEngineering

🟣لینک مقاله:
https://postgresweekly.com/link/176688/web


👑 @Database_Academy
🔵 عنوان مقاله
14x Faster with 12x Less Compute: Sometimes Postgres Really is All You Need

🟢 خلاصه مقاله:
تیم جیمز یک کلاستر ۱۲ سروره مبتنی بر HBase/OpenTSDB را که برای داده‌های سری‌زمانی استفاده می‌شد، با سامانه‌ای بسیار ساده‌تر بر پایه Postgres/Timescale جایگزین کرد. نتیجه: پرس‌وجوها تا ۱۴ برابر سریع‌تر، با ۱۲ برابر محاسبات کمتر، و ۱۰۰٪ دسترس‌پذیری پس از مهاجرت.

آن‌ها با تکیه بر SQL و قابلیت‌های Timescale مانند hypertable، فشرده‌سازی، continuous aggregates و خط‌مشی‌های نگهداشت داده، هم کارایی پرس‌وجوها و هم پایداری ingestion را بهبود دادند. طرح مهاجرت شامل dual-write، backfill موازی و اعتبارسنجی دقیق بود و در نهایت کل سامانه روی دو سرور با replication و failover خودکار پایدار شد.

پیام اصلی: برای بسیاری از بارهای کاری سری‌زمانی، Postgres/Timescale با طراحی درستِ شِما، ایندکس‌های هدفمند و ابزارهای استاندارد، هزینه و پیچیدگی عملیاتی را به‌طور چشمگیری کاهش می‌دهد و کارایی را بالا می‌برد—گرچه برای نرخ‌نوشتن یا کاردینالیته‌ی بسیار شدید، پایگاه‌های تخصصی هنوز مزیت دارند.

#Postgres #TimescaleDB #TimeSeries #OpenTSDB #HBase #DatabaseMigration #PerformanceEngineering #DevOps

🟣لینک مقاله:
https://postgresweekly.com/link/176022/web


👑 @Database_Academy
🔵 عنوان مقاله
ShadowTraffic's Postgres Connector (Tool)

🟢 خلاصه مقاله:
کانکتور Postgres از ShadowTraffic داده‌های تولیدشده را مستقیماً به Postgres استریم می‌کند و اختیار کامل مدیریت جدول‌ها را می‌دهد: ساخت خودکار، حذف و ایجاد مجدد، یا واگذاری کامل به فرآیندهای دستی/مهاجرت‌های موجود. با تنظیمات ساده می‌توانید رفتار insert، update و delete را کنترل کنید و نوع ستون‌ها، سرنخ‌های اسکیمای لازم و اندازه/بسامد دسته‌ها را دقیقاً سفارشی‌سازی کنید. نتیجه این است که می‌توانید داده را سریع شبیه‌سازی یا به‌تدریج تکامل دهید، در حالی‌که کنترل و شفافیت عملیاتی بر Postgres و بار وارد بر محیط را حفظ می‌کنید.

#ShadowTraffic #Postgres #DataStreaming #SyntheticData #DataGeneration #ETL #DatabaseTesting #DevTools

🟣لینک مقاله:
https://docs.shadowtraffic.io/connections/postgres/?utm_source=tldrdata


👑 @Database_Academy
🔵 عنوان مقاله
Did You Know Postgres Tables are Limited to 1,600 Columns?

🟢 خلاصه مقاله:
اگر نمی‌دانستید، در Postgres هر جدول حداکثر ۱۶۰۰ ستون می‌تواند داشته باشد. این یک محدودیت سخت در هسته سیستم است و با NULL بودن فیلدها یا TOAST دور زده نمی‌شود. اگر شماره issue 226 در سال 2017 را خوانده باشید، احتمالاً این نکته را به خاطر دارید. این سقف به معنای آن است که طراحی‌هایی با جدول‌های بسیار عریض—مثل هر شاخص یک ستون یا طرح‌های EAV تثبیت‌شده—به‌سرعت به حد می‌خورند. راه‌حل‌های بهتر شامل نرمال‌سازی، تفکیک عمودی، تبدیل ستون‌ها به سطرها برای سنجه‌ها، یا استفاده از JSONB برای ویژگی‌های کم‌استفاده و پراکنده است. جدول‌های خیلی عریض علاوه بر ریسک رسیدن به سقف، هزینه I/O و نگهداری را بالا می‌برند. نتیجه عملی: با در نظر گرفتن حد ۱۶۰۰ ستون، از طرح‌های باریک‌تر و انعطاف‌پذیرتر استفاده کنید و قبل از اعمال مهاجرت‌ها، تعداد ستون‌ها را بررسی کنید.

#Postgres #PostgreSQL #SQL #DatabaseDesign #DataModeling #SchemaDesign #JSONB #SoftwareEngineering

🟣لینک مقاله:
https://postgresweekly.com/link/176989/web


👑 @Database_Academy
🔵 عنوان مقاله
PostGraphile v5 Release Candidate

🟢 خلاصه مقاله:
** نسخه v5 از PostGraphile به مرحله Release Candidate رسیده است؛ ابزاری که مانند PostgREST برای RESTful، به‌صورت خودکار یک GraphQL API مبتنی بر Postgres می‌سازد و طرحواره GraphQL را از همان ساختار دیتابیس (جداول، ویوها و فانکشن‌ها) مشتق می‌کند. این RC نتیجه پنج سال کار است و نشان می‌دهد قابلیت‌ها تقریباً تکمیل شده‌اند و تمرکز روی پایداری و بازخورد دنیای واقعی است. برای تیم‌هایی که روی Postgres سرمایه‌گذاری کرده‌اند، PostGraphile لایه GraphQL را به‌خوبی با مدل رابطه‌ای همسو می‌کند و با تکیه بر ساختار و منطق موجود در دیتابیس، توسعه API را سریع‌تر و منسجم‌تر می‌سازد. در انتخاب مسیر، PostgREST برای APIهای ساده و RESTful مناسب است و PostGraphile زمانی می‌درخشد که انعطاف‌پذیری GraphQL مدنظر باشد. کاربران فعلی بهتر است قبل از ارتقا به v5، RC را در محیط آزمایشی امتحان کنند و یادداشت‌های انتشار و تغییرات احتمالی را مرور کنند.

#PostGraphile #GraphQL #Postgres #API #ReleaseCandidate #OpenSource #Backend #DeveloperTools

🟣لینک مقاله:
https://postgresweekly.com/link/176691/web


👑 @Database_Academy
🔵 عنوان مقاله
a new $8/mo 'developer tier'

🟢 خلاصه مقاله:
** یک پلن جدید با قیمت ماهانه ۸ دلار برای «developer tier» سرویس ابری مدیریت‌شده Postgres معرفی شده که دسترسی کم‌هزینه و قابل پیش‌بینی به دیتابیس را برای مراحل اولیه توسعه فراهم می‌کند. این پلن برای توسعه‌دهندگان مستقل، دانشجوها و تیم‌های کوچک—برای نمونه‌سازی، استیجینگ، CI/CD و پروژه‌های آزمایشی—طراحی شده و امکانات ضروری مانند اجرای مدیریت‌شده Postgres، پشتیبان‌گیری و مانیتورینگ پایه را ارائه می‌دهد. در ازای قیمت پایین، معمولاً محدودیت منابع دارد و قابلیت‌های پیشرفته تولیدی مثل HA یا چندمنطقه‌ای را شامل نمی‌شود. نقطه قوت آن مسیر ارتقا به پلن‌های بالاتر بدون دردسر و سازگاری کامل با اکوسیستم استاندارد Postgres است که هزینه و پیچیدگی میزبانی شخصی را کاهش می‌دهد.

#Postgres #DBaaS #CloudDatabase #DeveloperTier #SaaS #StartupTools #DevOps

🟣لینک مقاله:
https://postgresweekly.com/link/176986/web


👑 @Database_Academy
🔵 عنوان مقاله
ClickPipes for Postgres now supports failover replication slots.

🟢 خلاصه مقاله:
** این به‌روزرسانی اعلام می‌کند که ClickPipes for Postgres اکنون از failover replication slots پشتیبانی می‌کند؛ قابلیتی که در محیط‌های با قابلیت دسترس‌پذیری بالا باعث تداوم جریان داده هنگام جابه‌جایی از primary به standby می‌شود. با حفظ موقعیت اسلات در زمان failover، مصرف‌کنندگان CDC می‌توانند بی‌وقفه روی primary جدید ادامه دهند، بدون از دست‌دادن داده یا رشد غیرقابل‌کنترل WAL. این تغییر ریسک عملیاتی را کم می‌کند، پیاده‌سازی HA را ساده‌تر می‌سازد و برای تیم‌های Go که روی Postgres سرویس‌های داده می‌سازند—طبق پوشش آخرین شماره Golang Weekly—خبر مهمی است.

#Postgres #Replication #Failover #ClickPipes #Golang #CDC #HighAvailability #DataEngineering

🟣لینک مقاله:
https://postgresweekly.com/link/176987/web


👑 @Database_Academy
🔵 عنوان مقاله
What Do Postgres 18's New 'Index Searches' Lines in EXPLAIN Mean?

🟢 خلاصه مقاله:
در Postgres 18 خط جدیدی به خروجی EXPLAIN ANALYZE اضافه شده به نام Index Searches که تعداد «پروب‌های منطقی» به ایندکس را در طول اجرای هر نود نشان می‌دهد. این شمارنده با تعداد ردیف‌های تولیدشده فرق دارد: ممکن است یک جست‌وجوی ایندکسی ده‌ها یا صدها ردیف برگرداند (مثلاً در یک رِنج اسکن)، یا برعکس، تعداد زیادی جست‌وجو انجام شود اما خروجی کمی تولید شود.

این خط در نودهای مرتبط با ایندکس مثل Index Scan، Index Only Scan و Bitmap Index Scan دیده می‌شود و در طرح‌های پارامتری (مثلاً Nested Loop با Index Scan در سمت داخلی) بسیار کمک‌کننده است؛ معمولاً برای هر ردیفِ سمت بیرونی، یک Index Search ثبت می‌شود. اگر تعداد Index Searches بالا و خروجی کم باشد، احتمال تکرار پروب‌های غیرکارا وجود دارد و شاید بهتر باشد استراتژی جوین (مثلاً Hash Join)، طراحی ایندکس‌های ترکیبی یا خود عبارت‌های شرطی را بازنگری کنید.

برای تیونینگ، عدد Index Searches را در کنار rows و زمان‌بندی‌ها مقایسه کنید تا «هزینه هر پروب» و «انتخاب‌پذیری» را بهتر بفهمید. توجه کنید که این شاخص نشان‌دهنده پروب‌های منطقی است و مستقیماً بیانگر I/O فیزیکی نیست. همچنین در طرح‌های موازی به‌صورت هر-ورتکر/نود گزارش می‌شود و فقط با EXPLAIN ANALYZE در دسترس است. در مجموع، این قابلیت جدید دید دقیق‌تری از الگوهای دسترسی ایندکس، تناسب ایندکس و انتخاب استراتژی جوین به شما می‌دهد.

#Postgres #PostgreSQL18 #EXPLAINANALYZE #Indexing #QueryOptimization #DatabasePerformance #IndexScan

🟣لینک مقاله:
https://postgresweekly.com/link/176988/web


👑 @Database_Academy
🔵 عنوان مقاله
PostgreSQL Event Calendar

🟢 خلاصه مقاله:
PostgreSQL Event Calendar یک سایت متمرکز برای رصد رویدادهای مرتبط با Postgres است و یک فایل ICS / iCalendar هم ارائه می‌دهد که می‌توانید به تقویم خود اضافه کنید تا رویدادها را بدون پیگیری دستی دنبال کنید. فهرست رویدادها تا PGDay Austria در سپتامبر 2026 ادامه دارد که امکان برنامه‌ریزی بلندمدت را برای علاقه‌مندان و اعضای جامعه Postgres فراهم می‌کند.

#PostgreSQL #Postgres #iCalendar #ICS #TechEvents #DatabaseCommunity #PGDayAustria #OpenSource

🟣لینک مقاله:
https://postgresweekly.com/link/176673/web


👑 @Database_Academy
🔵 عنوان مقاله
Transaction Pooling in Postgres with Pgcat

🟢 خلاصه مقاله:
این مرور سه موضوع مرتبط در عملیات Postgres را کنار هم می‌گذارد: مدیریت اتصال‌ها با Transaction Pooling از طریق Pgcat، سفر یک پرس‌وجوی SQL درون Postgres، و نقش «Dirty Pages» در کارایی و دوام. در Transaction Pooling، Pgcat اتصال‌های سمت سرور را فقط در طول تراکنش قرض می‌دهد و با افزایش استفاده مجدد از Backendها، هزینه اتصال‌های کوتاه‌عمر را کاهش می‌دهد—به‌ویژه در بارهای Serverless و Microservices. بهای آن، حساسیت به حالت‌های سطح نشست است؛ پس باید وضعیت را داخل تراکنش نگه داشت و به زمان‌بندی‌ها، اندازه Pool و مشاهده‌پذیری توجه کرد. «سفر» Phil Eaton نشان می‌دهد پرس‌وجو چگونه از Parse/Rewrite/Plan به Execution می‌رسد، با تکیه بر آمار و ایندکس‌ها، MVCC، قفل‌ها، Shared Buffers و WAL. توضیحات Jesús Espino و Umair Shahid درباره Dirty Pages می‌گوید صفحاتِ تغییرکرده در حافظه برای کارایی خوب‌اند، اما باید با Checkpoint، Background Writer و تنظیمات WAL مدیریت شوند تا از جهش‌های تاخیری جلوگیری شود. کنار هم، این سه دیدگاه کمک می‌کنند با تغذیه کارآمد اتصال‌ها، فهم مسیر اجرای پرس‌وجو و تنظیم مسیر نوشتن، Postgres را سریع‌تر و قابل‌پیش‌بینی‌تر اجرا کنید.

#Postgres #Pgcat #TransactionPooling #ConnectionPooling #SQL #DatabaseInternals #DirtyPages #WAL

🟣لینک مقاله:
https://postgresweekly.com/link/176685/web


👑 @Database_Academy
1
🔵 عنوان مقاله
PGSync 5.0: Postgres to ElasticSearch/OpenSearch Syncing

🟢 خلاصه مقاله:
PGSync 5.0 یک میان‌افزار برای همگام‌سازی داده‌های Postgres با ElasticSearch/OpenSearch است. این ابزار تغییرات دیتابیس را به‌صورت لحظه‌ای دریافت می‌کند و آن‌ها را به اسناد ساخت‌یافته JSON تبدیل کرده و در ایندکس‌های جست‌وجو می‌نویسد. هدف آن کاهش پیچیدگی ETL سفارشی، پایداری و تاخیر پایین در به‌روزرسانی ایندکس‌ها است. PGSync از الگوهایی مثل backfill اولیه، استریم‌ تغییرات، denormalization، نگاشت انعطاف‌پذیر جدول‌به‌سند و upsertهای idempotent پشتیبانی می‌کند. در نسخه ۵ تمرکز بر کارایی، سادگی پیکربندی و سازگاری یکپارچه با ElasticSearch و OpenSearch است تا مسیر پایدار و سریعی از جدول‌های Postgres به اسناد قابل جست‌وجو فراهم شود.

#PGSync #Postgres #ElasticSearch #OpenSearch #CDC #SearchIndexing #DataSync #RealTime

🟣لینک مقاله:
https://postgresweekly.com/link/175730/web


👑 @Database_Academy
🔵 عنوان مقاله
PlanetScale for Postgres is Now GA

🟢 خلاصه مقاله:
PlanetScale اعلام کرد که PlanetScale for Postgres به مرحله GA رسیده و اکنون برای همه کاربران در دسترس است. این حرکت پس از آن انجام شد که شرکت در ماه جولای ورود خود به فضای PG را اعلام کرد و مجموعه‌ای از بنچمارک‌ها را منتشر نمود. این سرویس تا امروز در فاز private preview بود و اکنون برای استفاده در محیط‌های تولیدی آماده اعلام شده است. به این ترتیب، تیم‌هایی که بر Postgres تکیه دارند می‌توانند از پیشنهاد جدید PlanetScale استفاده کرده و آن را در مقیاس عملیاتی امتحان کنند.

#PlanetScale #Postgres #PG #Database #Cloud #GA #MySQL #DevOps

🟣لینک مقاله:
https://postgresweekly.com/link/174747/web


👑 @Database_Academy
🔵 عنوان مقاله
Building a Dev Experience for Postgres in VS Code

🟢 خلاصه مقاله:
مایکروسافت با حضور Rob Emanuele در پادکست Talking Postgres به میزبانی Claire Giordano درباره ساخت یک تجربه توسعه‌دهنده برای Postgres در VS Code صحبت می‌کند. محور گفتگو، افزونه تازهٔ «IDE for Postgres» است که اوایل امسال توسط Microsoft منتشر شد و هدفش آوردن کارهای روزمرهٔ پایگاه‌داده به دل محیط آشنای VS Code و کاهش جابه‌جایی بین ابزارهاست. در این قسمت به انگیزه‌ها، چالش‌های رایج برنامه‌نویسان، نقش بازخورد جامعه، و مسیر آیندهٔ ابزار پرداخته می‌شود تا نشان دهد این افزونه چگونه گردش‌کار نوشتن و آزمون SQL و مدیریت تغییرات را ساده‌تر می‌کند.

#Postgres #VSCode #Microsoft #DeveloperExperience #TalkingPostgres #IDE #DatabaseTools #VSCodeExtension

🟣لینک مقاله:
https://postgresweekly.com/link/176991/web


👑 @Database_Academy
🔵 عنوان مقاله
How to Listen to Database Changes Through the WAL

🟢 خلاصه مقاله:
شنیدن تغییرات دیتابیس از طریق WAL در Postgres یک روش پایدار برای CDC است که بدون تریگر و پولینگ اضافه، رویدادهای INSERT/UPDATE/DELETE را با ترتیب مبتنی بر LSN و قابلیت بازیابی استریم می‌کند. راه‌اندازی شامل wal_level=logical، ساخت replication slot، انتخاب output plugin مثل pgoutput یا wal2json، گرفتن snapshot اولیه و ذخیره LSN برای پیشرفت مصرف‌کننده است. از منظر عملیاتی باید نگه‌داری WAL توسط replication slot، backpressure، تراکنش‌های بزرگ، تغییرات schema، و مدیریت failover و امنیت را پایش کنید و با طراحی آیدمپوتنت در مقصد، تحویل at-least-once را کنترل کنید. در مطالب مرتبط، Peter Ullrich به transaction pooling با Pgcat و قیود آن می‌پردازد، Phil Eaton سفر یک کوئری SQL را در Postgres از parse تا execution روایت می‌کند، و Umair Shahid مفهوم Dirty Pages، نقش background writer/checkpointer و اثر تنظیمات بر پایداری I/O را توضیح می‌دهد.

#Postgres #WAL #ChangeDataCapture #LogicalDecoding #Pgcat #SQL #DirtyPages #DatabaseInternals

🟣لینک مقاله:
https://postgresweekly.com/link/176684/web


👑 @Database_Academy