[dead]
Making 768 servers look like 1
31–40 of 89 posts
Re: Making 768 servers look like 1
#32Earlier quoted context omitted.
Yeah, I'm looking at it in developer mode. It's using a GSAP timeline approach to update SVG properties. I'm curious how they handle security and caching for something like this. It looks like they're using Tailwind, at least. but this approach is really clean and nice. It really feels like the best way to learn is by studying other people's code.
What kind of security and caching concerns do they need to handle to animate an SVG?
I didn't explain myself very well. With iframes, there can be security concerns in general. Though in practice, there's usually no real issue. It just surfaces the surface level risk that JavaScript could be tampered with, but it's almost never something to actually worry about.
As for caching strategy, cache invalidation issues do pop up from time to time. Since the filenames usually include a content hash, I'm guessing they're using a Vite style caching strategy. Cache invalidation might almost never be a problem, but you still plan for it just in case.
Re: Making 768 servers look like 1
#33I disagree with the opening premise: > A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding Did you max out the capacity of the best server you can buy? Such a database can serve millions of customers (the numbers given). You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer insp…
Hetzner has this for 100usd a month, 256gb ram can handle quite a lot of traffic already €84.70 max. per month €0.1357 per hour CPU Intel Xeon E5-1650V3 RAM 256 GB Drives 2 × 6.0 TB Enterprise HDD Location #FSN1-DC1 Information IPv4 ECC iNIC
Lol that isn't a database server. Come on, if it has hard drives rather than (good) SSD in 2026, it's not a server you should be using for databases unless it's for something with next to no load, and you are also running your application server on the same machine.
Re: Making 768 servers look like 1
#34[flagged]
Re: Making 768 servers look like 1
#35I sometimes feel that when the industry moved from pets to cattle, what really happened is that the cattle turned out to need an exotic farm to live on, negating the savings. You can have a few honking servers or you can hand massage exotic k8s setups on your fleet. Pick your poison, but dont delude yourself that the TCO of the latter is lower than the former.
Re: Making 768 servers look like 1
#36Earlier quoted context omitted.
I found the article very helpful from a technical perspective, and didn't focus on the number too much, as it could easily be swapped and the decision-making process for when to shard is kinda out of scope. But I hadn't considered this, so thanks for pushing back. Good to keep in mind their incentives. I will say, since their product is a proxy whose interface is a single SQL connection, you should in theory be able…
> you should in theory be able to do dev queries through that black box Because it’s a leaky abstraction which is trying to make guarantees over network connections which are extremely difficult to make within the same kernel. A few questions I would start with: - is the system even ACID compliant? In my reading of this article, no. - is my sql feature set limited? Will it enforce all constraints? Or are their cross-…
Thank you, good points. I'm just learning about this in real time.
It looks like it does support transactions, but they basically destroy the performance benefits: https://vitess.io/docs/faq/sharding/advanced/can-i-use-vites...
The more I read the more I'm struggling to understand the benefit of a router like this that sits on top of a monolithic SQL, vs a truly distributed DB like cockroach.
Like you I'd love to learn more about the internals of their actual SQL engine, which is just barely touched on in the article. The idea of ripping out the layer of a SQL interpreter that does just enough to route it to a real server tickles my brain in the same way as when I learned how node.js ripped the js interpreter out of a browser.
Re: Making 768 servers look like 1
#37what did they use to make those diagrams/animations?
Re: Making 768 servers look like 1
#38Even with a large database servers (10s of CPU cores, 100s of gigabytes of RAM) bottlenecks arise pretty quickly.
Err, do they? For what percent of real world use cases?
The database can scale to handle more traffic by adding replicas. An extreme example of this is OpenAI's use of 50 replicas on a single Primary.
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"?
When we needed to store a petabyte of data (one million gigabytes), we'd need many more shards
For who? The United States government? How many end-users are running 1PB Postgres database on DBaaS?
Re: Making 768 servers look like 1
#39I disagree with the opening premise: > A single database server cannot handle such demand, so we must spread the queries and data out across many servers with database sharding Did you max out the capacity of the best server you can buy? Such a database can serve millions of customers (the numbers given). You always want to scale up the other parts first, request handlers, caching, etc. The day you can no longer insp…
Well, they are selling this thing so they don't want you to buy a big server (with a read replica) as that's much cheaper.
That's not true! We have demand for bigger machines and we also sell them. You can go checkout the PlanetScale website. See: https://x.com/samlambert/status/2077197049129587150
There are truly customers that bigger machine no longer cuts.
Disclaimer: I'm an Engineer at PS.
Re: Making 768 servers look like 1
#40I'm surprised no one has mentioned Multigres yet, they are the competitor of Neki. I'm a big fan of both and has been following them since they were announced last year. I think this blog post is the first time they are talking about the internals of Neki. In contrast, Multigres is being built in public since day 1, you can see their high-level architecture here [1], though I'm still waiting for more details on their sharding model.