Folks, in your launch posts remember to describe what you're launching and what it's for. Ideally in the opening paragraph.
- Intro: Explains problem but not what is Neki or what it's for.
- Why Neki: Explains alternatives and why they suck but not what is Neki or what it's for.
- How does Neki work: Describes the technical components but not what is Neki or what it's for.
- What you get beyond sharding: Explains how to run/deploy but not what is Neki or what it's for.
- What is a platform preview + Try Neki today: 140 words on the definition of "preview" and links to get started... but not what is Neki or what it's for.
Edit: The landing page has 100x more useful information up front -> https://neki.dev/
Edit #2: They've since added a "What is Neki" section. Good reaction time.
I scrolled through the landing page and even the "Get started" page and I have still no idea what is this. Is this a managed db? Something I can run myself? No idea.
The landing page which is linked at the start of the second sentence of this page…? I don’t completely disagree with you, but this is mostly hypertext working as intended, is it not?
Yeah this meta commentary on HN is very confusing for me. The structure of the article is literally
- short paragraph saying "we launched neki"
- short paragraph saying why neki was needed
- paragraphs about what neki is (with a header)
That seems like a very reasonable structure for a blog post like this one. Not being able to get to the third paragraph of a blog post seems like a "you" problem, not a blog problem.
I love the offer which is running on the "PlanetScale Metal".
They claim to provide unlimited IOPS (I/O operations Per Second).
I would like to get some of these drives myself. Sounds like a technical miracle.
On the other hand claiming such miracles makes me wonder which other aspects in this are are actually a working miracle or rather a mythos/false marketing claim.
The top concern I've gotten from dev teams when proposing HA distributed postgres (e.g through RDS Aurora global) is that eventual consistency is not suitable for many workloads.
Does Neki solve for this, and if so how? My understanding of CAP theorem is that this basically requires some compromises around availability, but I'm curious as to what that looks like in practice here.
Assuming it works the same way as their MySQL product, Vitess:
The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be.
I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)
Same here, first thing I need to know when considering a distributed system is how consistency is handled. If it's eventual consistency, what is the replication lag like? If it's strong consistency, can their network handle that? What happens when a node goes down?
I love how the Planetscale CEO has been shitting on multigres[0], Supabase's equivalent to Neki, and gloating about how superior Neki is, and yet Neki is not even open source!
Sam, it feels like you're just playing games. It's hard to take anything you say or do seriously. Are you going to OSS this thing? Or have you decided to backpedal?
Congrats on the checks notes closed launch, I guess?
They both are characteristics of software that people consider when deciding whether to use it.
Open source being by far the more important of the two, since it means the user is more insulated by terrible corporate decisions thus making it more suitable for long term planning.
I love to see this but as a heavy Vitess/MySQL user I do fear the split focus from PlanetScale. Hoping to see continued improvements on the Vitess side as well.
Selfish doubts aside, congrats to Planetscale on the launch!
don't worry, we still give a lot of love to vitess. at the end of the day they are both databases. the beauty of doing both is we can take learnings from each product and apply it to the other.
How are cross-shard joins and transactions handled? Are there query patterns that would require application changes despite using the same drivers and ORM?
I am on a 12 Muni right now that is plastered with a Neki ad, and I looked up neki.dev literally 10 mins ago to see what this product is about. Did they time the release of this bus ad with the launch date?
The first thing I want to know when looking at a distributed system is how consistency is handled, ctrl+f for "consis" on both the blog post and neki.dev has zero hits. So I can only assume it will have eventual consistency with a considerable replica lag for real-time systems.
The largest database to ever run on Aurora MySQL runs on PlanetScale, and the largest database to ever run on Aurora limitless also runs on PlanetScale.
We went as far as we could on GCP before PlanetScale. Spanner is amazing but also amazingly expensive. And CloudSQL, also amazing as long as you don’t need write scaling. PlanetScale (Vitess+MySQL plus their branching / deployment and monitoring tools) is just not a combination offered on GCP. And while I didn’t use Aurora, from talking to and exploring AWS it doesn’t really have this combination either.
I see no mention of foreign keys, or any other constraints, across shards. If, as I suspect, they're not implemented, it would still be useful but at the level of Spanner 10 years ago.
That is what the “regular” PlanetScale is all about. It uses the Vitess open source project to do write scaling through shading. It is very powerful and customizable and stable. It was built to run YouTube. Former happy user here.
Many of the engineers who built Neki also worked on Vitess for years. But it's a ground up new implementation designed to specifically target Postgres.
Sam is not an asshole. His twitter is great, he's definitely opinionated, and if you haven't had the luck of meeting him you might misread his tone as grumpy. It's not. It's sarcastic/dry humour and honest.
Perhaps he's quite nice over zoom, but since very few of us are going to meet him in that context, the rest of us are left to judge him by what he posts. And as they say, you never get a second chance to make a first impression.
Based on what I've read so far, with his shit-talking the competition, he seems like... a bit of an asshole.
> he just comes off as funny on twitter once you've met him.
Never heard of the guy before today, but his dickish, edge-lord aura (on X and in this thread) makes me not want to meet him. If I had to choose between buying from him, or some other random dude, I'll hear out the random dude first.
There's obviously more to the story than outsiders are aware, but personally it just leaves a bit of sour taste in my mouth when the tech and blog posts you guys put out are amazing.
Folks, in your launch posts remember to describe what you're launching and what it's for. Ideally in the opening paragraph.
- Intro: Explains problem but not what is Neki or what it's for.
- Why Neki: Explains alternatives and why they suck but not what is Neki or what it's for.
- How does Neki work: Describes the technical components but not what is Neki or what it's for.
- What you get beyond sharding: Explains how to run/deploy but not what is Neki or what it's for.
- What is a platform preview + Try Neki today: 140 words on the definition of "preview" and links to get started... but not what is Neki or what it's for.
Edit: The landing page has 100x more useful information up front -> https://neki.dev/
Edit #2: They've since added a "What is Neki" section. Good reaction time.
I scrolled through the landing page and even the "Get started" page and I have still no idea what is this. Is this a managed db? Something I can run myself? No idea.
Folks, your blog post sucks at marketing.
Edit: your marketing site actually has excellent marketing information.
Edit #2: They've since replaced the blog post with a link to the marketing page. Good reaction time.
The landing page which is linked at the start of the second sentence of this page…? I don’t completely disagree with you, but this is mostly hypertext working as intended, is it not?
Yeah this meta commentary on HN is very confusing for me. The structure of the article is literally
- short paragraph saying "we launched neki"
- short paragraph saying why neki was needed
- paragraphs about what neki is (with a header)
That seems like a very reasonable structure for a blog post like this one. Not being able to get to the third paragraph of a blog post seems like a "you" problem, not a blog problem.
1 reply →
Sadly, in 2026, you should never assume anyone will click a link.
1 reply →
I love the offer which is running on the "PlanetScale Metal".
They claim to provide unlimited IOPS (I/O operations Per Second).
I would like to get some of these drives myself. Sounds like a technical miracle.
On the other hand claiming such miracles makes me wonder which other aspects in this are are actually a working miracle or rather a mythos/false marketing claim.
The top concern I've gotten from dev teams when proposing HA distributed postgres (e.g through RDS Aurora global) is that eventual consistency is not suitable for many workloads.
Does Neki solve for this, and if so how? My understanding of CAP theorem is that this basically requires some compromises around availability, but I'm curious as to what that looks like in practice here.
Assuming it works the same way as their MySQL product, Vitess:
The usual way to run it is that you partition your db based on something like a user, so that single user gets a consistent DB, but anything cross-shard may not be.
I know when I worked at Block, Cashapp was using Vitess and getting cross-shard DB writes down and functioning correctly was one of the major blockers to adoption. (though I just did tls management for vitess and didn't write any workloads on top of it, so my impression might be a bit off)
Therefore, Consistency guarantees are based on implementing application-specific partitioning (correctly)?
1 reply →
Same here, first thing I need to know when considering a distributed system is how consistency is handled. If it's eventual consistency, what is the replication lag like? If it's strong consistency, can their network handle that? What happens when a node goes down?
[dead]
I love how the Planetscale CEO has been shitting on multigres[0], Supabase's equivalent to Neki, and gloating about how superior Neki is, and yet Neki is not even open source!
Sam, it feels like you're just playing games. It's hard to take anything you say or do seriously. Are you going to OSS this thing? Or have you decided to backpedal?
Congrats on the checks notes closed launch, I guess?
0: https://github.com/multigres/multigres
Every PlanetScale launch seems to come with a side of beef with the competition. Case in point: https://x.com/samlambert/status/2098069474205470970?s=20
Just launch the product and let it speak for itself. The constant need to take shots at competitors comes across as pretty childish.
Wow, that thread has bro energy maxed out. Is this normal modern way of communicating for top leaders or i'm getting old?
2 replies →
How does open source have anything to do with Neki's ability to scale against a service that doesn't even do sharding.
They both are characteristics of software that people consider when deciding whether to use it.
Open source being by far the more important of the two, since it means the user is more insulated by terrible corporate decisions thus making it more suitable for long term planning.
13 replies →
Do they get the same backlash if they went with a source available license similar to MongoDB or Elastic?
Kinda ironic that Planetscale built their company on open source Vitess that google built
And now planetscale have made a Vitess like equivalent for Postgres which they have made proprietary
They have made it proprietary so that providers like AWS can't build their own service with it, thus eating into PS's income.
Google is big enough to survive open-sourcing Vitess, k8s, angular, etc. Planetscale isn't.
correct. AWS do anti-competitive stuff to us all the time we can't make it any easier for them.
Google, Azure, and AWS already have their highly available PostgreSQL alternatives.
I need this for my side project that has zero users, but I wonder if Neki will scale well enough.
have you tried simultaneously vertically and horizontally scaling?
My plan is to automatically boot a new Kubernetes cluster for every db query.
I wonder how the performance will be, but I can just rewrite everything in Rust.
1 reply →
I love to see this but as a heavy Vitess/MySQL user I do fear the split focus from PlanetScale. Hoping to see continued improvements on the Vitess side as well.
Selfish doubts aside, congrats to Planetscale on the launch!
don't worry, we still give a lot of love to vitess. at the end of the day they are both databases. the beauty of doing both is we can take learnings from each product and apply it to the other.
[dead]
How are cross-shard joins and transactions handled? Are there query patterns that would require application changes despite using the same drivers and ORM?
Is this going to be open sourced? I thought this was the plan at the start. But ow I am confused.
Man, I was deep into this blog post before I was able to answer the question "what is Neki?".
https://neki.dev/ is a much more terse overview of neki
Now that's a nice release page.
If I don't know what I'm reading about by the third or fourth phrase, I skip it. Empty language comes from empty minds and I don't have time for that.
I am on a 12 Muni right now that is plastered with a Neki ad, and I looked up neki.dev literally 10 mins ago to see what this product is about. Did they time the release of this bus ad with the launch date?
Bus ads have been running for a little while now. A few billboards around too.
Neki is a sharded Postgres implementation. It introduces one level of indirection between the application and the Postgres shards.
Found this from neki.dev.
You can also find that in first section of the linked post (after the intro)...
How does Neki compare to https://pgdog.dev/?
it works and does sharding
Same here! Except:
- PgDog is open source
- It runs anywhere, not just your cloud
- It's built for Postgres, not a MySQL pivot
1 reply →
So apparently the neki router uses many parts of Postgres. But is it open source itself?
Apparently not.
The first question came to my mind was, how would this compare against Citus.
I actually wrote a bit about this on our blog! https://planetscale.com/blog/the-history-of-postgres-shardin...
Not even freeware/shareware?
A C2 level diagram included in the blog post would be helpful. What are the drawbacks to using Neki aside from the obvious (new software has bugs)?
The first thing I want to know when looking at a distributed system is how consistency is handled, ctrl+f for "consis" on both the blog post and neki.dev has zero hits. So I can only assume it will have eventual consistency with a considerable replica lag for real-time systems.
Nice work by the marketing department getting two posts on HN front page at same time.
It doesn’t take a marketing person to submit a link.
Pretty exciting to see a sharded Postgres product in the market.
The pitch is compelling. I wonder how many teams will be able to operate sharded database setups in production as a result of this.
Obviously welcome more tools for Postgres and sharding but it’s a tough hill to climb against the hyper clouds. Best wishes to the team.
The largest database to ever run on Aurora MySQL runs on PlanetScale, and the largest database to ever run on Aurora limitless also runs on PlanetScale.
What do you mean? Your comment reads like PlanetScale uses Aurora under the hood, you mean PlanetScale can handle bigger DB’s than Aurora?
1 reply →
We went as far as we could on GCP before PlanetScale. Spanner is amazing but also amazingly expensive. And CloudSQL, also amazing as long as you don’t need write scaling. PlanetScale (Vitess+MySQL plus their branching / deployment and monitoring tools) is just not a combination offered on GCP. And while I didn’t use Aurora, from talking to and exploring AWS it doesn’t really have this combination either.
It makes me so happy to hear you had a good experience. Thank you for being a customer.
I see no mention of foreign keys, or any other constraints, across shards. If, as I suspect, they're not implemented, it would still be useful but at the level of Spanner 10 years ago.
Cross shard transactions are “coming soon”. So, this is just like having multiple postgres clusters.
Cross shard transactions are supported, but we don't have support for atomic 2pc cross shard transactions, its WIP
2 replies →
I think this will become the new standard.
is this open-sourced?
Cool, but we're on MySQL - anything similar available? Percona XtraDB?
That is what the “regular” PlanetScale is all about. It uses the Vitess open source project to do write scaling through shading. It is very powerful and customizable and stable. It was built to run YouTube. Former happy user here.
TiDB: Distributed and MySQL compatible
Vitess/Planetscale? Neki is essentially a version of Vitess for Postgres fom the same guys.
Many of the engineers who built Neki also worked on Vitess for years. But it's a ground up new implementation designed to specifically target Postgres.
[dead]
MariaDB Galera or Vitess.
Independent of the product, love the branding design for this page.
What does this compete with? Google Cloud SQL?
Multigres is the one that comes to mind
Once they implement sharding...
7 replies →
It's not Open Source Software. So, I'm not even interested. Lol
lol are you an amazon customer?
lol are you an amazon wannabe?
1 reply →
Will this be open source at some point?
undecided right now
Site design is tight. I like it.
thank you!
only planet scale? Rookie numbers.
I am looking for interdimensional and interuniversal scale. Which of you trust fund babies has a startup which is working on this problem?
i have been struggling to hire enough physicists
can we choose read-after-write consistency at query time, if needed?
[flagged]
The tech might be amazing, but the CEO comes across as an asshole
Sam is not an asshole. His twitter is great, he's definitely opinionated, and if you haven't had the luck of meeting him you might misread his tone as grumpy. It's not. It's sarcastic/dry humour and honest.
They build good stuff and care.
You can build good stuff, care, and be very opinionated...you can also be all of those things and still be an asshole.
being opinionated doesn't mean you can attack people you compete or don't like every other week
His X.com persona is def that of an asshole.
very kind of you to say tony
He's actually quite nice over zoom so he just comes off as funny on twitter once you've met him.
Perhaps he's quite nice over zoom, but since very few of us are going to meet him in that context, the rest of us are left to judge him by what he posts. And as they say, you never get a second chance to make a first impression.
Based on what I've read so far, with his shit-talking the competition, he seems like... a bit of an asshole.
> he just comes off as funny on twitter once you've met him.
Never heard of the guy before today, but his dickish, edge-lord aura (on X and in this thread) makes me not want to meet him. If I had to choose between buying from him, or some other random dude, I'll hear out the random dude first.
3 replies →
I can fully understand why someone would think that.
There's obviously more to the story than outsiders are aware, but personally it just leaves a bit of sour taste in my mouth when the tech and blog posts you guys put out are amazing.
(I'm a paying PS customer)
Genuine question, since I'm a little out of the loop; why do you say that?
https://x.com/samlambert/status/2098069474205470970?s=20
https://x.com/samlambert/status/2098075451373834681?s=20
6 replies →
I, for one, like it when CEOs let loose a bit and show some personality. It's better than everyone walking around talking like a media trained robot.
[dead]
[dead]