Databricks ने serverless Postgres विशेषज्ञ कंपनी Neon का अधिग्रहण किया

• Databricks ने डेवलपर-केंद्रित serverless Postgres प्रदान करने वाली Neon के अधिग्रहण पर सहमति की है
• Neon storage और compute के अलग-अलग आर्किटेक्चर के माध्यम से डेवलपर्स और AI सिस्टम्स के लिए अनुकूलित serverless database platform प्रदान करती है
• Neon को अपनाने के बाद AI agents द्वारा बनाए गए databases का अनुपात 30% से बढ़कर 80% से अधिक हो गया है
• Databricks और Neon open source दर्शन और infrastructure innovation DNA साझा करते हैं
• अधिग्रहण के बाद भी Neon platform का समर्थन और भविष्य-केंद्रित roadmap Databricks के संसाधनों से और मजबूत किया जाएगा

---

अधिग्रहण की घोषणा और उसका महत्व

• Databricks ने डेवलपर-केंद्रित serverless Postgres प्रदान करने वाली Neon के अधिग्रहण पर सहमति की है
• Neon के सह-संस्थापक उन गिने-चुने वैश्विक विशेषज्ञों में हैं जो storage और compute की पूर्ण separation architecture के साथ Postgres डिज़ाइन कर सकते हैं
• यह टीम AI युग में बड़े पैमाने पर डेवलपर समर्थन के लिए serverless Postgres platform उपलब्ध कराने पर केंद्रित रही है

Postgres आधारित innovation mission

• Neon के सह-संस्थापकों ने लगभग 4 वर्ष पहले पुराने database architecture में बदलाव लाने के उद्देश्य से साथ काम शुरू किया था
• मुख्य लक्ष्य इस प्रकार थे
  • Postgres के de facto standard बनने का पूर्वानुमान लगाते हुए serverless platform की vision तैयार करना
  • डेवलपर्स कुछ ही सेकंड में नया instance बना सकें, इसके लिए speed पर ध्यान देना
  • database के auto-scaling और operations को सरल बनाकर over- और under-provisioning की चिंता कम करना
  • तुरंत branching और forking support देकर database testing और experimentation को आसान बनाना
• Neon टीम ने storage और compute की independent scaling वाली architecture बनाकर इन लक्ष्यों को हासिल किया
• लॉन्च के बाद डेवलपर्स ने इसकी speed, simplicity और Git-शैली branching/forking सुविधाओं की सराहना की

AI agents के युग में बदलाव

• Neon के GA के बाद AI agents ने कुल DB creation का 30% हिस्सा लेना शुरू किया, जो हाल में बढ़कर 80% से अधिक हो गया
• AI agents की ज़रूरतें अब डेवलपर्स जैसी हो गई हैं
• Neon की प्रमुख ताकतें इस प्रकार हैं
  • Postgres open source ecosystem: नवीनतम LLMs को Postgres data पर train किया गया है, इसलिए AI agents Neon के उपयोग में सहज हैं
  • तेज़ी: इंसानों से भी अधिक गति की आवश्यकता होने के कारण ultra-fast instance provisioning अनिवार्य है
  • लचीली scaling और pricing: अलग serverless architecture के कारण बहुत कम लागत पर बड़ी संख्या में AI agents को support किया जा सकता है
  • branching और forking: AI agents के लगातार बदलते प्रयासों के लिए experimentation और validation आसान हो जाता है

Databricks और Neon का साझा DNA

• संस्थापक Nikita Shamgunov, Heikki Linnakangas, Stas Kelvich उद्योग के प्रसिद्ध DB तकनीकी विशेषज्ञ हैं
• SingleStore, Postgres committer जैसी पृष्ठभूमियों के साथ इनके पास समृद्ध अनुभव और मौलिकता है
• Databricks और Neon दोनों infrastructure layer में अत्याधुनिक innovation और open source मूल्यों को महत्व देते हैं
• Apache Spark और Postgres दोनों UC Berkeley से शुरू हुए open source projects हैं, यह भी एक साझा कड़ी है

आगे की vision और users के लिए लाभ

• OLTP database market (लगभग 100 billion dollar आकार) अभी भी कई दशक पुराने products पर आधारित है
• अब डेवलपर्स और AI agents के नेतृत्व में innovation का समय है
• Databricks और Neon का लक्ष्य सबसे developer-friendly और AI-agent-friendly DB platform बनाना है
• मौजूदा Neon customers और partners लगातार support और innovation तथा roadmap के कार्यान्वयन की अपेक्षा कर सकते हैं
• Databricks के संसाधनों से platform को मजबूत करने और स्थिर growth सुनिश्चित करने की योजना है
• Data + AI Summit (San Francisco, 9–12 जून) में आगे की vision विस्तार से साझा की जाएगी

[GN⁺]

Hacker News टिप्पणियाँ

• मुझे लगता है कि open source की वजह से data warehousing तेज़ी से commodity बनता जा रहा है। मेरी जानकारी की एक कंपनी 2 petabyte से ज़्यादा डेटा Cloudera में स्टोर करती थी, लेकिन cloud (Databricks) पर जाने के बजाय उसने Iceberg, Trino, Superset से अपना analytics platform बनाया और लागत 5 गुना बचाई। enterprise-grade k8s operators अब काफ़ी अच्छे हो चुके हैं, और on-premise S3 भी शानदार है। 128 CPU और 1TB memory वाले servers जैसे अच्छा hardware और networking भी उपलब्ध है। सिर्फ Trino ही नहीं, StarRocks और ClickHouse भी enterprise-grade k8s Helm charts/operators देते हैं। Databricks की 60 billion dollar valuation उनका अपना बोझ है। उन्हें इस कीमत को justify करना होगा, और उनका core business खुद भी commodity बन रहा है। Neon उनके product lineup की उस कमी को भरता है जहाँ operational (row-oriented) DB नहीं था
  • enterprise के नज़रिए से यह commodity नहीं है। मेरी पिछली नौकरी open source software, या ऐसी कंपनी जो 10 साल बाद शायद रहे ही नहीं, या ऐसी कंपनी जो हमारे tenant के बाहर कहीं data रखे—इनमें से किसी को अनुमति नहीं देती थी। वे “call for pricing” model को भी पसंद करते थे, और इस बात से कि अब data platform की चिंता नहीं करनी पड़ेगी, Databricks को अपनाना मेरी top 3 उपलब्धियों में था। नया platform लाने में risk बहुत बड़ा होता है, इसलिए (किसी भी open source project पर) भरोसा नहीं किया जा सकता। हमने एक बार startup solution अपनाया था, लेकिन क्योंकि वह MongoDB इस्तेमाल करता था और ops team के पास क्षमता कम थी, सीखने के बजाय Atlas जैसी fully supported service का contract लिया। अनजान Azure firewall के बजाय वही firewall इस्तेमाल किया जिसे हम जानते थे, और तरह-तरह के contracts भी किए। hiring कम हुई, संपर्क का एक ही point रहा, और operational efficiency मिली। startup license सालाना 5~10K dollar का होता है, लेकिन support पर 40K dollar जैसे बहुत ज़्यादा खर्च लगते हैं। startup और enterprise पूरी तरह अलग दुनिया हैं
  • मैं open source StarRocks को k8s operator के साथ इस्तेमाल करके terabyte-scale data पर customer analytics कर रहा हूँ, और मेरे environment में Databricks की लगभग कोई ज़रूरत महसूस नहीं होती
  • पिछले कुछ सालों से ClickHouse बिना किसी समस्या के बहुत अच्छी तरह इस्तेमाल कर रहा हूँ। इसकी feature breadth काफ़ी बड़ी है, और यह भरोसेमंद database है। external dictionary feature की वजह से Postgres, Redis जैसे दूसरे datastores के साथ integration आसान है
  • अगर आप Kubernetes operator आधारित open source Cloudera alternative ढूँढ रहे हैं, तो stackable.tech इस पर 5 साल से काम कर रहा है। on-premise open source S3 वाली तरफ़ समस्या है। MinIO की सिफारिश नहीं करूँगा, और इसके अलावा enterprise-grade solutions लगभग खाली हैं
  • data warehousing तो कई दशक पहले से commodity है। price/performance metrics का लंबा इतिहास है, और SnowBricks products इस कसौटी पर खरे नहीं उतरते। बस फर्क इतना है कि यह hard sell है या soft sell
  • समझ नहीं आता Databricks से operational DB क्यों खरीदना चाहिए। यह बस market valuation बनाए रखने के लिए Databricks की जद्दोजहद लगती है
  • अगर Databricks को सिर्फ row DB चाहिए होता, तो वह खुद Postgres बना लेता। Neon पर इतना पैसा खर्च करना इस बात का संकेत है कि Neon में “independently scalable storage and compute” जैसी कोई खास चीज़ है जो Databricks चाहता था
  • जानना चाहता हूँ कि आप ETL के लिए क्या इस्तेमाल करते हैं
• मैंने पिछले हफ़्ते neon में apply किया था, और acquisition की ख़बर आते ही आज सुबह तुरंत rejection मिल गया। यह अब तक का सबसे खुशहाल rejection experience रहा। यह तीसरी बार है जब मैं लगातार ऐसी कंपनी में शामिल होने के क़रीब पहुँचा जिसे बाद में acquire कर लिया गया, इसलिए अब बस stability चाहता हूँ। neon team को बधाई। मुझे neon पसंद है और मैं इसका इस्तेमाल भी करता हूँ, बस उम्मीद है कि इस acquisition के बाद यह बहुत ज़्यादा न बदले
  • acquisition से पहले मैं Kenna Security में शामिल हुआ था, और एक महीने बाद उसे Cisco ने acquire कर लिया। वह सच में भयानक अनुभव था, और Kenna leadership वाली किसी कंपनी या Cisco में मैं फिर कभी काम नहीं करूँगा
  • मेरा अनुभव उल्टा रहा। acquisition के समय join करना सबसे दिलचस्प दौर था। मेरे मामले में acquisition integration का अनुभव होने की वजह से मुझे अक्सर scout किया गया
  • engineering manager के पहले साल में मैं acquisition process के बीच था, जहाँ दो rounds of layoffs झेलते हुए किसे रखना है यह चुनना पड़ा और team restructuring में मदद करनी पड़ी। morale बहुत गिर गया था, और culture भी बिल्कुल fit नहीं था। बहुत बुरा burnout हुआ, कुछ महीनों का break लिया, और अब फिर से IC के रूप में खुश होकर काम कर रहा हूँ
  • मेरा अनुमान है कि neon team को Databricks की Online Tables technology में absorb किया जाएगा। product के लिहाज़ से भी यह समझ में आता है
  • अगर किसी ने neon की पुरानी valuation के समय join किया हो और vesting अभी-अभी पूरी हुई हो, तो शायद अचानक अच्छी-ख़ासी रकम मिली होगी—सोचता हूँ वह कैसा रहा होगा
• Databricks मेरे इस्तेमाल किए गए software में सबसे ज़्यादा चिढ़ पैदा करने वाला कचरा है। हैरानी होती है कि कोई इसे अपनी मर्ज़ी से इस्तेमाल करता है
  • Databricks की शुरुआत 2013 में हुई थी, जब Spark खास नहीं था, और इसने Spark को बेहतर और तेज़ बनाया। product अब भी Spark-centric है, लेकिन मेरा मानना है कि Iceberg और DuckDB का combination 95% कंपनियों के लिए बेहतर है। यह सस्ता है, तेज़ है, संभालना आसान है, और हम Definite में भी इसी premise पर data platform बना रहे हैं (ETL, BI, Data Lake सब शामिल)
  • Databricks data के लिए Jira जैसा है। कोई इसे इस्तेमाल नहीं करना चाहता, यह खास अच्छा भी नहीं है, और सब users को fit करने की कोशिश में जो feature soup बना है, उसकी हर चीज़ आधी-अधूरी लगती है। अब इससे कहीं बेहतर alternatives हैं, इसलिए मैं अपनी पसंद से Databricks कभी नहीं चुनूँगा
  • सच कहूँ तो मैं इससे बिल्कुल सहमत नहीं हूँ। Hadoop background से आने के नाते Databricks मेरे लिए utopia है। यह stable है, fast है, और बड़े datasets पर शानदार scale करता है। बस मेरी सबसे बड़ी शिकायत इसकी बहुत ज़्यादा कीमत है
  • मुझे पहले Databricks platform पसंद था। 2020~2021 में AWS, Azure, Snowflake के मुक़ाबले practically Databricks ही एक reasonable alternative था। अभी हालत यह है कि features की भरमार, लगातार बदलाव, acquisitions आदि की वजह से सब बिखरा हुआ लगता है, और feature names भी गड़बड़ हैं
  • तो IBM-टाइप software (“सब इस्तेमाल करते हैं, इसलिए हम भी”) के लिए अब भी market बचा हुआ है
  • सच कहें तो Databricks बहुत boring product है। late 2010s को याद करें तो Spark-as-a-Service शानदार था, और उस समय enterprises अपने दम पर Spark को reliably चलाने में असफल हो रहे थे। hyperscalers की first-party services भी कमज़ोर थीं, और Databricks notebook format की Jupyter compatibility जैसी समस्याएँ भी थीं, लेकिन on-prem clusters की instability उससे बड़ा headache थी, इसलिए premium देना मंज़ूर था। उस समय Databricks एक शानदार 1 billion dollar business था। लेकिन सिर्फ Spark-aaS के दम पर unicorn नहीं बना जा सकता था। AWS EMR धीरे-धीरे competitor की तरह पास आ रहा था, और आखिर में Databricks ने product को बेइंतहा फुलाकर growth strategy पर दांव लगाया—data, lake, house जैसे buzzwords की बौछार के साथ। 2025 में Databricks की गिरावट enshittification का कड़वा उदाहरण है। हो सकता है किसी दिन Larry Ellison इसे acquire कर ले और यह market से गायब हो जाए। आजकल कोई नए project में Databricks क्यों चुनता है, यह समझ नहीं आता, लेकिन जो enterprises 5 साल से ज़्यादा समय से इसका इस्तेमाल कर रहे हैं, वे आसानी से बाहर नहीं निकलेंगे। आगे market share गिरेगा, लेकिन कुछ समय तक पैसा कमाता रहेगा। यही industry cycle है, और आख़िर में entropy जीतती है। मैं इससे नफ़रत नहीं करूँगा। इसने काफ़ी अच्छी history बनाई है
  • Serverless पर बहुत ज़ोर दिया जाता है, लेकिन इसकी limits और hidden pitfalls इतने ज़्यादा हैं कि सच में पागल कर देते हैं
  • मुझे हमेशा शक रहा है कि Spark hosting वाकई इतनी revolutionary थी भी या नहीं। और Spark खुद 90% established companies की data processing ज़रूरतों के लिए बहुत complex नहीं है क्या? समझ नहीं आता इस कंपनी की valuation इतनी ऊँची क्यों है
  • अगर cookies disable कर दें तो website बिल्कुल नहीं खुलती, और यह बहुत बड़ा red flag है। जो कंपनी एक website तक ठीक से नहीं बना सकती, उसके अच्छे digital products बनाने पर भरोसा नहीं होता
• Databricks, Oracle जितना ही खराब है। पूरा यक़ीन है कि यह Neon को भी बिगाड़ देगा या महँगा बना देगा। medium to long term में मैं Neon के alternatives ढूँढने वाला हूँ
  • Databricks की M&A strategy acquired companies का दम घोंटने वाली लगती है। Iceberg, DuckDB जैसे open source upheaval के सामने यह जूझ रहा है। acquisitions के ज़रिए innovation लाने की कोशिश करता है, लेकिन company culture की वजह से acquired companies टूट जाती हैं। मैं big data industry background (पूर्व Snowflake) से हूँ, इसलिए पक्षपाती हो सकता हूँ, लेकिन open source के लगातार मज़बूत होने का trend साफ़ दिखता है। यह बदलाव कहाँ जाता है, इसे लेकर बहुत जिज्ञासा है
• लेख से उद्धरण: “पिछले साल जब Neon GA में गया, तब उसकी 30% databases AI agents ने बनाई थीं, लेकिन हाल में फिर देखने पर यह अनुपात 80% से ऊपर था। यानी AI ने इंसानों से 4 गुना ज़्यादा DB बनाए।” यह ऐसा data है जो कई alarms बजाता है। लगता है Databricks Postgres को AI solution की तरह package करना चाहता है। अजीब ज़माना है
  • उनमें से कितने DB active use में हैं, यह जानना चाहता हूँ
• Neon team को बधाई। मुझे उनका बनाया हुआ बहुत पसंद है। लेकिन ईमानदारी से कहूँ तो Databricks के साथ इसका connection या synergy समझ नहीं आती, और उम्मीद है Neon एक अलग product के रूप में बना रहे। नहीं तो market एक साफ़-सुथरा Postgres provider खो देगा
  • Azure पर इसकी dependency ज़्यादा है, इसलिए शायद यह तुरंत गायब नहीं होगा। Databricks शायद analytics DB से आगे बढ़कर transactional DB क्षेत्र में भी विस्तार करना चाहता है
  • FAQ में कहा गया है कि यह independently operate करेगा, लेकिन मुझे लगता है असल नतीजा पहले से तय है
• मुझे HN पर Neon team की पहली post याद है। तब भी मैंने comment किया था कि यह शानदार idea है, और हालाँकि मुझे अभी तक इसे सीधे इस्तेमाल करने की ज़रूरत नहीं पड़ी, मुझे लगा था कि किसी दिन करूँगा। लेकिन ऐसी acquisition news देखकर संशय होता है। चिंता है कि अब focus users के बजाय owners पर चला जाएगा। सैद्धांतिक तौर पर दोनों के हित एक जैसे होने चाहिए, लेकिन व्यवहार में ऐसा कम ही होता है
  • मुझे भी Neon की पहली post याद है। storage-compute separation ताज़गीभरा लगा था, और मैंने Pageserver के बारे में सवाल भी पूछा था। फिर 2 साल बाद मैं खुद Turso database में इसी तरह के separated storage पर काम करने लगा। Neon team को फिर से बधाई
  • acquisition news सुनकर मैं भी ठिठक गया। यह मानना मुश्किल है कि AI users को प्राथमिकता देना developers के हितों के साथ मेल खाता है। उम्मीद है PostgreSQL core से जुड़ी technology को open source community का फायदा मिलेगा
• Neon team को बधाई। शानदार product। बेशक, VC funding लेने पर ऐसा नतीजा काफ़ी हद तक तय होता है। उम्मीद है Nikita वगैरह Databricks में घुल-मिलकर अपनी पहचान नहीं खोएँगे और मज़बूत बने रहेंगे
• यह सच में दिलचस्प development है। मुझे लगता है OLTP और OLAP का convergence सही दिशा है। मैंने OP के साथ SingleStore में HTAP system बनाने का अनुभव किया है। हमने OLTP और OLAP को एक single database में लाने की कोशिश की थी (एक बार copy करके दोनों को support करने के लिए), लेकिन HTAP ठीक से काम नहीं कर पाया। OLTP के लिए Postgres अलग, OLAP के लिए data warehouse/lake अलग, और दोनों के बीच replication को efficiently design करना चाहिए। synchronous replication बहुत मुश्किल है। columnar storage OLTP writes को अच्छी तरह handle नहीं कर पाता। उत्सुकता है कि क्या Databricks और Neon “latest Postgres tables को सीधे Unity Catalog में इस्तेमाल” करने वाला scenario सच कर पाएँगे (Debezium, Kafka, Flink, Iceberg के बिना, और Spark खुद Iceberg state maintenance संभाले)
  • क्या OP से आपका मतलब Neon के founder Nikita Shamgunov (पूर्व MemSQL/SingleStore founder) है?
• Neon team को बधाई। सच कहूँ तो थोड़ा अफ़सोस है। मुझे उम्मीद थी कि CockroachDB के business source पर जाने से जो खाली जगह बनी, उसे Neon भरेगा। Databricks द्वारा acquire होने के बाद Neon कम आकर्षक लग रहा है। किसी बड़ी कंपनी पर critical infrastructure की ज़िम्मेदारी छोड़ना भरोसेमंद नहीं लगता। “modern” Postgresql की मांग काफ़ी है, लेकिन direct alternatives में से कोई भी मूल भावना से ज़्यादा दूर नहीं जा रहा—चाहे pricing हो, compatibility हो, या source availability। Postgres alternatives देखते समय मैंने यह तुलना की
  (1) AWS RDS पहले से इस्तेमाल कर रहा था, लेकिन यह महँगा था, और scalability व operations की समस्याएँ थीं
  (2) AWS Aurora कुछ operational समस्याएँ हल करता है, लेकिन दूसरे नुकसान लाता है, और दूसरे wire-compatible Postgres alternatives जैसी सीमाएँ रखता है
  (3) CockroachDB बहुत दिलचस्प था, लेकिन toolchain compatibility और deep compatibility issues थे, और उस समय यह open source था
  (4) Neon अभी अपरिपक्व लगा इसलिए अपनाया नहीं, लेकिन यह दिलचस्प था और लगता था कि कई समस्याएँ हल कर सकता है
  (5) Yugabyte भी दिलचस्प technology है, लेकिन उसमें भी कई compatibility issues थे
  मैंने खुद Postgres host करने पर भी विचार किया था, लेकिन Kubernetes और Postgres को self-manage करना भारी बोझ लगा। self-replication या operational features अभी पर्याप्त mature नहीं थे, और upgrades के समय पूरा data unload/reload करना बहुत झंझट भरा था। scaling या automation आसान नहीं था
  • Yugabyte के query engine के Postgres-based होने की बात पर तुलना करने वाले को याद दिलाया गया कि Neon खुद Postgres है
  • “सबसे अच्छा modern Postgres alternative, (5 साल बाद का) Postgres खुद है” — ऐसा अपना short-term अनुभव साझा किया
  • मैं यह और सुनना चाहूँगा कि दूसरे wire-compatible Postgresql alternatives की वे “एक जैसी कमियाँ” कौन-सी हैं