हमने अपना ग्राहक डेटा वेयरहाउस पूरी तरह Postgres पर बनाया
केवल PostgreSQL पर customer data warehouse बनाना—Fivetran या BigQuery जैसे tools के बजाय foreign data wrappers और pg_cron जैसी सुविधाओं का उपयोग करके—सादगी और एक परिचित, एकल stack का वादा करता है, लेकिन scalability और long-term maintainability को लेकर सवाल भी उठाता है। Commenters इस बात पर बहस करते हैं कि business logic और orchestration को database के भीतर कितनी दूर तक ले जाया जाए, stored procedures के परीक्षण, debugging और refactoring के लिए कमजोर tooling की तुलना में external ETL/orchestration frameworks और columnar warehouses की परिपक्वता का हवाला देते हुए। चर्चा यह भी दिखाती है कि Postgres-based platforms के लिए स्पष्ट positioning और पारदर्शी pricing कितनी महत्वपूर्ण है, जो अधिक specialized analytics stacks की जगह लेना चाहते हैं।
डेटा वेयरहाउस के रूप में Postgres बनाम विशेषीकृत वेयरहाउस
- कुछ लोगों को एक Postgres-only “warehouse” सादगी और कम टूल-फैलाव के कारण आकर्षक लगता है, खासकर जब डेटा वॉल्यूम मध्यम हो।
- अन्य लोग तर्क देते हैं कि Postgres, BigQuery, Snowflake, Redshift, ClickHouse जैसे कॉलमनर वेयरहाउस की तुलना में analytics के लिए “स्केल नहीं करता”, खासकर भारी aggregation और लंबे retention के मामलों में।
- आलोचक नोट करते हैं कि यह तरीका अक्सर केवल छोटे data windows (जैसे 30 दिन) रखने का मतलब होता है, जिसे cheap columnar storage को देखते हुए कई व्यवसाय अपर्याप्त मानेंगे।
- pg_analytics, ParadeDB, S3-backed storage, Neon-like architectures जैसे columnar/analytics extensions और projects का उल्लेख है, जो Postgres को warehouse use cases की ओर बढ़ाने के तरीके हैं।
डेटाबेस के अंदर Business Logic
- एक धड़ा: “Postgres को सिर्फ data store के रूप में इस्तेमाल करें।” pg_cron pipelines, भारी PL/pgSQL, या Supabase-style APIs/permissions को in-DB रखने से बचें; इन्हें test करना, debug करना, refactor करना, और नए engineers को समझाना कठिन होता है।
- विरोधी धड़ा: अच्छी तरह डिज़ाइन किए गए functions, triggers, row-level security, और PostgREST APIs सुरक्षा को काफी बेहतर बना सकते हैं और bugs कम कर सकते हैं, खासकर access control और integrity constraints के लिए।
- “vendor lock-in” की चिंता उठाई जाती है, लेकिन अन्य लोग जवाब देते हैं कि Postgres-specific features पर निर्भर होना performance और capabilities के लिहाज़ से उचित है।
Tooling, Testing, और Migrations
- बहुत से लोग database logic के लिए कमजोर ergonomics की शिकायत करते हैं: general-purpose languages की तुलना में सीमित IDE support, refactoring, और documentation generation।
- अन्य लोग उभरते हुए tools की ओर इशारा करते हैं: postgres_lsp, DataGrip/JetBrains IDEs, pgpkg, skeema-like approaches, PL/pgSQL linters, test frameworks, Docker/Testcontainers-based integration tests, और SQL के versioning व testing के लिए Liquibase/Flyway/dbt।
- व्यापक सहमति है कि SQL objects को Git के तहत files में रखना और migrations या declarative tools के जरिए deploy करना ही sanity बनाए रखने की कुंजी है।
Foreign Data Wrappers और Data Movement
- कुछ लोग Fivetran/Airbyte जैसे tools के बजाय सरलता के लिए FDWs को पसंद करते हैं; अन्य लोग बड़े या जटिल cross-database queries के लिए गंभीर performance issues रिपोर्ट करते हैं और ETL tools या middle-tier code को प्राथमिकता देते हैं।
- चर्चा किए गए व्यावहारिक DW patterns में atomic refreshes के लिए schema swapping, लंबे locks से बचने के लिए chunked copying, और pg_cron के बजाय external schedulers (cron/ECS) शामिल हैं।
परिभाषाएँ, Streaming, और Product Feedback
- कई लोग तर्क देते हैं कि वर्णित system “सिर्फ एक database” या “customer usage metrics” है, full data warehouse नहीं।
- Postgres पर streaming/continuous queries में रुचि है (जैसे Materialize-like behavior, Debezium-based roll-your-own, epsio.io), लेकिन मौजूदा विकल्पों को या तो भारी या अधूरा माना जाता है।
- कई commenters Tembo की website की स्पष्ट positioning की कमी और pricing को गहराई में छिपाने के लिए आलोचना करते हैं, एक visible pricing page और interest capture करने के non-intrusive तरीकों (जैसे simple newsletter forms) की अपील करते हैं।