Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
bddicken
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
bddicken
1mo ago
pgBaseBackup seems very cool. It's great that they got support to continue building. We just don't use it presently.
2.
▲
by
bddicken
2mo ago
Neki will support cross-shard ACID transactions with a combination of an external transaction coordinator and some changes to PostgreSQL itself to support this (either by engine modifications or extensions). I expect as part of that, we
3.
▲
by
bddicken
2mo ago
Exactly. When you have a router + query parser in front of the db nodes, the burden of managing multiple versions simultaneously can be taken out of the app and into the database layer.
4.
▲
by
bddicken
2mo ago
Broadly for Pg, minor version upgrades are straightforward as the data on disk is guaranteed to be compatible. All it takes is a restart or switchover to upgrade. Major versions are more challenging for "vanilla" Postgres because
5.
▲
by
bddicken
2mo ago
What I emphasized in this article (author here) is scaling postgres backups. This works because there's already rock-solid systems built into postgres + surrounding tooling to build from. The broader takeaway is the principle of, "
6.
▲
by
bddicken
2mo ago
Author here, thank you. Technically, they are using js + gsap + svg embedded i the article with iframes. Process-wise, I drafted most of them as static images in excalidraw, passed the images along to cursor for a first draft, applied styli
7.
▲
by
bddicken
2mo ago
Very welcome
8.
▲
by
bddicken
2mo ago
Yep! https://vitess.io/docs/reference/features/distributed-transa...
9.
▲
by
bddicken
2mo ago
We have tons of customers who do exactly this. It's great. Sharding is for customers who out grow this path.
10.
▲
by
bddicken
2mo ago
A lot of what you're referring to is dictated by the sharding strategy. Vitess and Neki both let you configure this via the VSchema / data topology (That's what I'm getting at here) https://planetscale.com
11.
▲
by
bddicken
2mo ago
You should read through those articles.
12.
▲
by
bddicken
2mo ago
> So an extreme example is OpenAI needing 50 replicas, but we're doing five blades ... err, we're doing 768 servers because the need arose "pretty quickly"? If you read the OpenAI article, you'll see that they ac
13.
▲
by
bddicken
2mo ago
Hey, author here. Technically, they're powered by js + gsap + svg. Process wise (for most of them) I sketched them out in advance in excalidraw for figure out layout, then passed these along to cursor to have it build out an initial dr
14.
▲
by
bddicken
2mo ago
Spreading requests out across hundreds, thousands, and in some cases even more is precisely what is done in the industry for big databases! Good examples: cashapp: https://code.cash.app/planetscale-metal github: https:
15.
▲
by
bddicken
2mo ago
Caching at all levels is key to good db performance (cpu cache <-> ram <-> disk). CPU cache optimization is not my area of expertise, but I did write another fun article on io devices and how it related to databsae perf: https:
16.
▲
by
bddicken
2mo ago
Hey, I wrote this! Sharding is cool and foundational to making the internet work. I'm around to answer Qs.
17.
▲
How to not screw up a benchmark
(planetscale.com)
3 points
by
bddicken
4mo ago
|
0 comments
18.
▲
Managing Postgres traffic spikes at Figma
(figma.com)
4 points
by
bddicken
4mo ago
|
0 comments
19.
▲
by
bddicken
5mo ago
It may not have the popularity it once did, but MySQL still powers a huge % of the internet.
20.
▲
by
bddicken
5mo ago
What about spanner specifically benefits from random ids over sequential ones?
21.
▲
by
bddicken
5mo ago
Simple sequential IDs are great. If you want UUID, v7 is the way to go since it maintains sequential ordering.
22.
▲
by
bddicken
5mo ago
+1
23.
▲
by
bddicken
5mo ago
I've also written about sharding. https://planetscale.com/blog/database-sharding
24.
▲
by
bddicken
5mo ago
B+trees combined with sequential IDs are great for writes. This is because we are essentially just appending new rows to the "linked list" at the bottom level of the tree. We can also keep a high fill % if we know there isn't
25.
▲
by
bddicken
5mo ago
It's really just a matter of tradeoffs. B-trees are great, but are better suited for high read % and medium/low write volume. In the opposite case, things like LSMs are typically better suited. If you want a comprehensive resource
26.
▲
by
bddicken
5mo ago
I've read this paper and it's a neat idea. It hasn't been introduced into popular oss databases like postgres and mysql, and my understanding is it has some drawbacks for real prod use vs ths simplistic benchmarks presented i
27.
▲
by
bddicken
5mo ago
Oh hey, I wrote this! Happy to chat more about the article here. Databases are kinda my thing.
28.
▲
20 Years of Postgres Performance
(vondra.me)
2 points
by
bddicken
6mo ago
|
0 comments
29.
▲
Scaling Postgres Connections with Pgbouncer
(planetscale.com)
1 points
by
bddicken
6mo ago
|
0 comments
30.
▲
Add AI to Any App
(simeongriggs.dev)
1 points
by
bddicken
6mo ago
|
0 comments
More ›