Neki – Sharded Postgres

Original Article ↗ Hacker News Discussion ↗

A new sharded PostgreSQL service called Neki, built by PlanetScale, is drawing interest for bringing Vitess-style horizontal scaling to Postgres while remaining a proprietary, hosted offering. Commenters focus on practical concerns such as how it handles consistency, cross-shard transactions, constraints, and resharding in comparison to tools like Citus, Multigres, and PgDog, noting that technical guarantees are not yet clearly documented. The launch also triggers debate over marketing clarity, the decision not to open-source the system in an AWS-dominated cloud landscape, and the public communication style of PlanetScale’s leadership.

What Neki Is and Positioning

  • Described as a sharded PostgreSQL system with a router layer adding indirection between apps and Postgres shards.
  • Marketed as “Vitess-like but for Postgres,” built by engineers with Vitess experience, but claimed to be a ground‑up implementation for Postgres.
  • Intended to handle online resharding and high-scale workloads; runs only as a managed service from the provider, not “anywhere.”

Documentation, Messaging, and Marketing

  • Many readers struggled to understand “what Neki is” from the launch blog; landing page was seen as clearer.
  • Some felt the post lacked a concise top‑level description and consistency guarantees; edits later added a “What is Neki” section and eventually redirected to the marketing page.
  • Design and branding received praise, but some still found the product model (fully managed vs self‑hosted) unclear.
  • A few comments noted coordinated marketing (ads, multiple HN posts).

Sharding, Transactions, and Consistency

  • Questions about:
    • How cross‑shard joins and transactions work.
    • Whether cross‑shard foreign keys and constraints are supported.
    • Consistency model (strong vs eventual, read‑after‑write options, replica lag).
  • Representatives say:
    • Cross‑shard transactions exist but not yet with fully atomic 2PC; that’s in progress.
    • The router does not share code with Postgres.
  • Several ask for a clear guarantees page and architecture/C2 diagrams; current docs called “AI‑like” or vague by some.

Feature Gaps and Unclear Areas

  • Cross‑shard foreign keys and constraints appear absent; some compare this to older versions of other distributed databases.
  • Handling of very large tables (e.g., 8B+ rows) and whether a single table can span multiple shards is unclear.
  • Consistency behavior and failure scenarios are not fully documented in the thread.

Open Source vs Proprietary Debate

  • Multiple commenters care strongly about open source for long‑term safety and vendor risk; some say they’re uninterested in closed source.
  • The company is “undecided” on open‑sourcing Neki but emphasizes needing protection from large cloud providers replicating the service.
  • Some point out the irony that the company itself is built on an open source project while keeping Neki closed.

Comparisons to Other Systems

  • Comparisons raised with: Citus, Multigres, pgdog, Supabase’s offering, Aurora, Cloud SQL, Spanner, Vitess/PlanetScale MySQL, MariaDB Galera, TiDB.
  • Representatives stress that Neki already supports sharding and online resharding, while claiming some competitors lack mature sharding yet.
  • Competing open source projects highlight benefits of being self‑hostable and non‑proprietary.

Perception of Company Culture and Tone

  • Significant side discussion about the CEO’s public behavior and posts criticizing competitors.
  • Some find the aggressive, sarcastic style entertaining or refreshingly honest; others view it as unprofessional, off‑putting, or a reason to avoid the product.
  • Debate over whether confrontational defense of a commercial/open‑core model is justified or counterproductive.