DatabricksがNeonを買収！その狙いは？

＞あなたはホントに“どっちつかず”だから
個人的には、こういう状況に雇われることの強みはここだと思うな
どちらの会社にも既存の偏見がないし、それに伴うめんどくさい荷物もない
両方のやり方の長所短所を見ることができるし、それに応じて動けるんだ

買収時にEMだったんだけど、その後の2回のレイオフを乗り越えなきゃいけなかったんだ
チームを再編成して、誰を残すか決めるグループにも入ってたよ
士気は最悪だったし、文化も全然合わなかった
それが原因でかなり燃え尽きて、今はICに戻って楽しく働いてるよ

＞これで彼らが変わりすぎないといいんだけどな
俺の予想だと、このチームはOnline Tables techに組み込まれるだろうね
製品的には理にかなってると思う

うん、俺もそうだと思うよ
Databricksはここ数年DynamoDBとかCosmosDBにお金を払ってきたんだ
だけど、Neonはリアルタイムワークロードに必要なスペックじゃないんだ
高性能AIにはね
CockroachとかAerospike、RonDBみたいな他の候補もいくつか予想してたんだけどな

俺、過去のスタートアップ買収経験から言うけど、創業者かよほどのエクイティがないと買収は割に合わないよ。俺たち現場で統合のために働くのに、創業者は報われてすぐいなくなったり力奪われたりするんだ。

10億ドルって多分全部現金じゃないだろうね。かなりの部分はDatabricksの換金しにくい株式だと思うよ。

DatabricksはSparkが中心だけど、今はIcebergとDuckDBの組み合わせの方が安くて速くて分かりやすいから、ほとんどの会社にはそっちで十分じゃないかな。俺たちはDefinite[0] って製品をそういう考えで作ってるよ。

あなたが言ってた代替案、IcebergとDuckDBって、両方ストレージソリューションじゃないの？Sparkは分散コンピューティングを表現する方法だよね？
この分野からちょっと離れてたんだけど、もっと新しい分散コンピューティングのやり方ってあるの？

Databricksはデータ版のJiraみたいなもんで、誰も使いたがらないクソツールだよ。機能は多いけどどれも微妙だし、今はもっと良い代替がある。自分で選んで使うことは絶対ないね。

いや、マジで同意できないな。
Hadoop使ってた身からすると、Databricksはユートピアだよ。安定してるし、速いし、massive datasetsを扱ってもめちゃくちゃ上手くスケールする。
一番不満があるとすれば、マジで値段が高すぎることだけだね。

Serverlessをマジでゴリ押ししてくるけど、制限とかsurprise gotchasがめちゃくちゃ多いんだよ。もうほんと頭おかしくなりそう。

どんな選択肢を使ってるの？俺、Databricksで働いてるわけじゃないけど、自分のデータ基盤スタートアップを立ち上げようとしてるんだ。
だから”良い”ってのがどんな感じか聞きたいな！

Flink．の方がさ，今のところSparkより勢いあるよね．

スタートアップ作るほどでもないかなー．Neonは面白かったけど，OSSが成熟しちゃって後追いはきつい感じ．OSSをそのまま使うのがいいかもね．

俺さ，昔はあのプラットフォームの大ファンだったんだよ．だって2020年とか2021年頃はさ，AWSとかAzureとかSnowflakeと比べても，データプラットフォーム作るならマジで唯一まともな選択肢だったんだもん．でも今はフィーチャークリープとピボット＆買収が多すぎてダメになっちゃった．機能の名前付けがクソ下手なのもマイナスだね．

SparkはHadoopからマジで大きな進歩だったよな．でも最近はTrinoとか何でもいいから，そういうの使えばいいじゃん．データ扱う新しい方法がたくさん出てきてて，どれもSparkがHadoopから進歩したみたいに，人間工学的にも，パフォーマンスも価格もSparkよりずっと進化してるんだぜ．

あ，俺のスタートアップはPostgresじゃなくて，GPUで高速化したSparkの方なんだよね．これこれ → https://news.ycombinator.com/item?id=43964505
データ製品でさ，こういうUXはマジ勘弁ってのある？嫌いなUX教えてほしいな．

”momentum”って言葉はさ，難しいよね．ZigはC++より勢いあるけど，あの言語を追い越せるか？俺は無理だと思うね．

それにさ，明らかにめっちゃ高い傾向があるんだ！機能少ないのに価格が4倍～5倍とか…

duckdbはクエリエンジンだよ．データがあるS3上のparquetとかを直接クエリできるのが強み．分散ワークロードの実験例もあるけど，まだ実験段階．これね ― https://www.definite.app/blog/smallpond

ねえねえ，みんなが一番困ってる制限とか落とし穴って何？俺，このチームのメンバーなんだ．ペインポイントについて聞きたいんだよね．

もしこれらの疑問の答えが見つかったら、その結論に至った経緯についてのブログ記事は絶対読むよ。これからも面白い質問続けてね！ じゃあね。

Sparkをホスティングするのってそんなに画期的なのかな？それにさ、Sparkってエンタープライズのデータ処理の90％には複雑すぎない？この会社の評価額が全然理解できないんだけど。なんでそんな高いの？

DuckDBはストレージソリューションだけじゃないんだよ。それは保存されてる様々なファイル形式を、何も再保存せずに直接クエリできるんだ。それがウリの一つで、S3とかに置いてあるアーカイブやログデータを「”ingest”」する必要もなく、すでに保存してるデータを複製するのに二重にお金払わなくて済むんだ。

IBMみたいな「みんなこれが使ってるから！ きっと良いはず！」って感じのソフトウェアやプラットフォームの市場は、どうやらまだ飽和してなかったみたいだね。

Trino（AWS Athenaとして使ったんだけど、それはまだTrinoがPrestoって呼ばれてた頃の話ね）のことは本当にどれだけ褒めても足りないくらいだよ。「”どんどん増えていくCSV／JSON／Excel／Parquet／その他なんでも”」の山を、変換したり他のシステムに入れたりせずに、そのままSQLでクエリできるようにしたのは、ものすごく印象的だったな。本当にすごい技術の成果だよ。

Hadoopはそもそも、大きなデータファイルのバッチ処理システムであって、データウェアハウス（DW）の概念が扱っていたようなオンラインのレポーティングや分析のワークロードには全く向いてなかったんだ。その上にPigとかHiveとかHBaseとか後続のツールをいくら重ねても、その根本的な事実は決して変わらなかったんだよ。

もしコスト（またはパフォーマンス）が問題なら、うちは超効率的でGPUで速くした、使いやすいSparkを今作ってるところだよ。詳しくはここ見てね： https://news.ycombinator.com/item?id=43964505

多くの人が気づき始めてるんじゃないかな、実際には分散処理ってそんなに必要ないんだって。シングルノードのDuckDBでもかなりいけるし、そっちの方がずっとシンプルだよ。

最近DuckDBを使い始めたんだけど、この機能めっちゃ興奮するわ。完全に新しいパラダイムだね。科学者とか、たぶん他の多くの人にとっても最高のツールだよ。もっと早く真剣にやってればよかったなー。

でも…でも…君たちのこと追跡しないと！それが僕らのサイトの全目的なんだからさ /s

Sparkのいいとこはね、scala/python/RのAPIがあることだよ。これのおかげでSQLのめんどくさいこと（特に複数カラムに同じ変換する時とか）たくさん避けられるんだ。

今ね、ParaQuery（GPUアクセラレート版のSparkだよ）で別のSparkベースのやつ作ってるんだ。詳細はこれ見て→ https://news.ycombinator.com/item?id=43964505

Databricksってさ、Oracleレベルでヤバいんだよ。きっとNeonをダメにするか、めっちゃ高くするに決まってる。だから中長期的には、Neonの代わりに使えるものを探し始めるつもりだよ。

DatabricksのM&A戦略は買収先をダメにするようにできてる。IcebergやDuckDBみたいなオープンソースの流れに苦戦してるんだ。買収でイノベーションやろうとしても、社風が買収した会社を潰しちゃう。元Snowflakeで今は tower.dev をやってる俺は偏見あるかもだけど、Icebergとかに支えられたオープンソースのトレンドはマジで来てる。これからどうなるかマジで気になるね。

記事にあったんだけど、Neonが去年のGAの時、DBの30%がAIエージェント製だったのが、最近80%超になったって。AIが人間の4倍DB作ってるってこと。
これヤバくない？ DatabricksはPostgresをAIソリューションって売り込みたいみたいだけど。マジ変な時代だわ。

で、それらのDB、どれくらいが今もちゃんと使われてるんだろうな…

Neonチームおめ！（俺、彼らが作ったもの好きなんだよね）。でもさ、Databricksとの価値とか関係性が全然わかんないんだよな。Neonがこのまま独立した製品として続いてくれるといいんだけど。じゃないと、市場から頼りになるPostgresのプロバイダーがいなくなっちゃうからさ。

Azureでは結構使われてるから、なくなるってなったらビックリするね。これはDBX（Databricks）が分析DBだけじゃなくて、トランザクションDBの分野にも進出するための戦略だよ。

HNでNeonチームの最初の投稿を覚えてるよ。当時、すごく良いアイデアだってコメントした気がする。まだ使う必要はなかったけど、いつか使うと思ってた。正直、この買収で立ち止まるのって俺だけ？
新しいオーナーのニーズにもっとフォーカスしないといけなくなるのが心配。ユーザーのニーズとは理論上は一致するはずだけど、実際にはそうならないことが多い気がするんだ。

＞HNでNeonチームの最初の投稿を覚えてるよ。当時、すごく良いアイデアだってコメントした気がする。
それな！俺も覚えてるよ。結構面白かったんだよね。storageとcomputeの分離って新しい発想で、Pageserver[0]について質問したんだ。データベース開発のキャリアの進め方についても聞いたっけ[1]。
2年後、Turso databaseで似たようなdisaggregated storageに関わることになったよ。Neonチーム、おめでとう！
[0] - https://news.ycombinator.com/item?id=31756671
[1] - https://news.ycombinator.com/item?id=31756510

俺も立ち止まってる…IA向けのサービス提供と開発者向けのサービス提供は一致しないと思うんだ。PostgreSQLのコアに関わる部分の仕事がコミュニティの助けになることを願ってる。

Neonチームおめでとう。素晴らしいプロダクトだよ。これを見るのは悲しいけど、VCから資金調達してたら避けられないことだよね。Nikitaたちが強く踏みとどまって、Databricksにbit.io化されないことを願うよ。

Neonチーム、おめでとう。
正直、これは俺にとって少し悲しいことだな。CockroachDBが“business source”になった後にNeonがその空白を埋めてくれることを期待してたんだ。DataBricksに買われたことで、俺にとってNeonの興味はかなり薄れたよ。過去に買収で問題を抱えたことがあるような大組織が、俺にとってほぼ一番重要なインフラを本当に気にかけてくれるなんて信用できないんだ。
より“モダン”なpostgresqlへの需要は確実にあるけど、直接の代替案はほとんどが根本からかなり離れてる。価格設定、互換性、ソース公開とかね。
昔、postgresの代替を探してた時に検討したのはこれらだったんだ。
1. AWS RDS: すでに使ってたけど、高いしスケーリングや運用に問題があった。
2. AWS Aurora: 最終的に推奨されたやつで、運用問題は解決したけど他のニッチな欠点があった。他のワイヤ互換なpostgresql代替案とほぼ同じ欠点だね。
3. CockroachDB: すごく面白かったし、ワイヤ互換だったけど、深い互換性問題があった。当時はオープンソースだったけど、俺たちのツールには合わなかった。
4. Neon: 当時はまだ未熟だと見なされてたけど、確かに興味深かったし、俺たちの課題のほとんどを解決できそうに見えた。postgresqlの運用問題以外はね。当時はそれ以上深く調べなかった。
5. Yugabyte: 面白い技術だけど、互換性問題もあった。でも他のよりは少なかったな。俺が見る限り、彼らもpostgresqlのクエリエンジンを使ってるからね。
他にも、CloudPGみたいないろんな自前ホスティングユーティリティも見たけど、Kubernetesとpostgresqlのステートフルなデプロイを自分たちで維持するリソースがなかったんだ。俺たちの要件のほとんどは満たせただろうけど、KubernetesとPostgreSQLの両方でメンテナンス負担が増えるからね。
PostgreSQL単体でのホスティングは、その時点では十分成熟したレプリケーションや運用機能がなかったんだ。着実に成熟はしてるけど、データベースがたくさんあったから手動でのアップグレードやパッチ適用はすごく時間かかるだろうし。PostgreSQLにはメジャーアップグレードでちょっと面倒な癖があるんだよね。基本的に全データをアンロードしてリロードしないといけない。この問題を回避するために拡張機能や他のサービスを使わない限りね。

＞5. Yugabyte: 面白い技術だけど、互換性問題もあった。でも他のよりは少なかったな。俺が見る限り、彼らもpostgresqlのクエリエンジンを使ってるからね。
NeonはPostgresそのものだよ。

だから俺は他の多くとは違ってNeonに期待してたんだ。でもYugabyteはただのpostgresじゃないからね。