🔵 عنوان مقاله
the original 1986 paper
🟢 خلاصه مقاله:
**این متن به مقاله‌ی سال ۱۹۸۶ می‌پردازد که اهداف طراحی Postgres را تعریف کرد و نشان می‌دهد چگونه همان دیدگاه، امروز در PostgreSQL به‌خوبی محقق شده است. تمرکز مقاله بر قابلیت توسعه‌پذیری، پشتیبانی از داده‌های پیچیده، تضمین‌های تراکنشی و معماری پایدار است و نتیجه می‌گیرد که تصمیم‌های اولیه بسیار آینده‌نگرانه بوده‌اند؛ به‌طوری‌که «سازندگان PostgreSQL واقعاً عالی از پس آن برآمده‌اند.»
#Postgres #PostgreSQL #DatabaseSystems #DBMS #SystemsResearch #DataManagement #SoftwareArchitecture
🟣لینک مقاله:
https://postgresweekly.com/link/174750/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
the original 1986 paper
🟢 خلاصه مقاله:
**این متن به مقاله‌ی سال ۱۹۸۶ می‌پردازد که اهداف طراحی Postgres را تعریف کرد و نشان می‌دهد چگونه همان دیدگاه، امروز در PostgreSQL به‌خوبی محقق شده است. تمرکز مقاله بر قابلیت توسعه‌پذیری، پشتیبانی از داده‌های پیچیده، تضمین‌های تراکنشی و معماری پایدار است و نتیجه می‌گیرد که تصمیم‌های اولیه بسیار آینده‌نگرانه بوده‌اند؛ به‌طوری‌که «سازندگان PostgreSQL واقعاً عالی از پس آن برآمده‌اند.»
#Postgres #PostgreSQL #DatabaseSystems #DBMS #SystemsResearch #DataManagement #SoftwareArchitecture
🟣لینک مقاله:
https://postgresweekly.com/link/174750/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
"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
www.morling.dev
"You Don't Need Kafka, Just Use Postgres" Considered Harmful
Looking to make it to the front page of HackerNews? Then writing a post arguing that "Postgres is enough", or why "you don’t need Kafka at your scale" is a pretty failsafe way of achieving exactly that. No matter how often it has been discussed before, this…