Databricks acquires Neon
Databricks product perceptions
- Several commenters describe Databricks as bloated, confusing, “Jira-like,” and driven by feature creep, pivots, and bad naming.
- Others strongly defend it: compared to Hadoop-era stacks, Databricks is seen as stable, fast, and transformational for large-scale analytics—just very expensive.
- Serverless Databricks gets specific criticism: missing
persist()/caching, limited configuration, difficulty monitoring usage, awkward Unity Catalog constraints, and higher cost vs classic clusters.
Spark and data stack alternatives
- Multiple posts argue Spark is overkill for most workloads; Iceberg + DuckDB, Trino/Presto, ClickHouse, StarRocks, and similar stacks are seen as cheaper, simpler, and often faster.
- Some insist many teams don’t need distributed compute at all; a single-node DuckDB can cover most needs.
- Flink is mentioned as having more “momentum” than Spark for streaming; GPU-accelerated Spark startups also appear in the thread.
Reaction to the acquisition
- Strong mix of congratulations and disappointment: many fear this is the “beginning of the end” for Neon as an independent, dev‑friendly Postgres provider.
- Prior Databricks acquisition of bit.io (shut down quickly) is repeatedly cited as a warning; people expect price hikes, deprecation, or product distortion.
- Some Neon users immediately start scouting alternatives and say they’d be “insane” not to.
Trust, track record, and OSS concerns
- Neon staff link an FAQ and reaffirm plans to keep Neon Apache-2.0, but many say such assurances are historically unreliable after acquisitions.
- Key anxiety: Databricks is seen as sales/enterprise driven; Neon as product/DX driven. Users doubt these cultures will align.
- The partially closed control plane and complexity of self-hosting Neon are noted; the open-source storage architecture is considered the real value.
Why Databricks might want Neon
- Several see this as part of the Databricks vs Snowflake arms race and a move into operational/OLTP databases to complement their warehouse/lakehouse.
- Others frame it as a defensive hedge: if fast Postgres + replicas (or Neon-like tech) solves most companies’ needs, fewer will grow into Databricks.
- Some are excited about tighter OLTP–OLAP integration: fresh Postgres tables exposed directly in Unity Catalog without heavy CDC pipelines.
Neon features and alternatives
- Neon is praised for: disaggregated Postgres on object storage, scale-to-zero, copy-on-write branching, and good developer experience.
- Concerns focus on Databricks potentially degrading these: worse DX, enterprise-only focus, or weakened free tier.
- Suggested alternatives include Supabase, Xata, Prisma Postgres, DBLab Engine, Koyeb, generic managed Postgres, or even self-hosting.
Broader data ecosystem themes
- Commenters argue data warehousing is being commoditized by open-source (Iceberg, Trino, ClickHouse, StarRocks), undermining high SaaS valuations.
- Some expect more cash acquisitions of “serverless + AI-adjacent” startups with high multiples.
- A recurring split appears between enterprise buyers preferring integrated “data platforms” (like Databricks) and smaller teams favoring lean, OSS-centric stacks.