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.