201–210 of 228 posts
Earlier quoted context omitted.
What would DNS look like if it were released in 2025?
...and what should it look like?
Earlier quoted context omitted.
What would DNS look like if it were released in 2025?
Owned by GoogleFlare with public spec, but most of it would be run as closed source application that uses extended spec akin to EEE - making it impossible to use without relying on GoogleFlare. config defined in YAML.
Earlier quoted context omitted.
Personally, I'd say you should definitely add a disclaimer, otherwise a discussion that would likely gain traction is that the information might be being intentionally concealed.
I will add them in subsequent posts. The information is all over our site (they are on our portfolio page, and we wrote about them when we invested) but I am happy to reiterate on each post for each company
The resistance to a seemingly obvious correction seems a little shady. Expecting people to dig around a site to find out your position of financial interest is not reasonable.
Such behavior is disappointing, especially from a top HN account holder.
It's too bad, because otherwise there are some interesting ideas, but TFA is lacking in good faith.
Two gaps I keep hearing in this thread that could unblock adoption:
1. Reference architectures: serverless (Workers/Lambda) patterns, auth/VPN/stunnel/WireGuard blueprints, and examples for “OLGP control plane + TB data plane.”
2. Scaling roadmap: the single-core, single-leader design is philosophically clean—what’s the long-term story when a shard/ledger outgrows a core or a region’s latency budget?
Also +1 to publishing contentious, real-world case studies (e.g., “fee siphon to a hot account at 80–90% contention”) with end-to-end SLOs and failure drills. That would defuse the “100–1,000 TPS” debate and make the tradeoffs legible next to Postgres, FDB, and Redis.
I really like the work Joran and his team have done around DST, distributed systems awareness, and performance practices. I especially love the craziness around no dependencies (well, could you consider an underlying OS a dependecy?). But I've always felt the way they treat normal OLTP (they call OLGP) seems unfair. For example, comparisons using clear sub-optimal interactive SQL transactions for financial workloads,…
> comparisons using clear sub-optimal interactive SQL transactions for financial workloads, like locking rows rather than using condition checks at commit time Could you give an example of how the same transaction could be written poorly with "locking rows" and then more optimally with "using condition checks at commit time"?
vs. "lock this row so it can't change while I subtract 50 from 50,000,000,000,000..." you get the point
I really like the work Joran and his team have done around DST, distributed systems awareness, and performance practices. I especially love the craziness around no dependencies (well, could you consider an underlying OS a dependecy?). But I've always felt the way they treat normal OLTP (they call OLGP) seems unfair. For example, comparisons using clear sub-optimal interactive SQL transactions for financial workloads,…
Hey Dan, appreciate the compliment. Do you think it would be more fair to suggest that OLTP workloads have 0% contention? That debit/credit sets never intersect? In practice, we're seeing that our customers are already some of the largest brokerages, wealth managements or exchanges, in their jurisdictions, even national projects, and all of them with decades of Postgres etc. experience, some even running installation…
I don't think they have 0% contention, and I agree that contention is the bane of a dev's existence, but I don't think it's as cut and dry as only looking at Amdahl's.
Specialized systems have done really well to handle contention: My go-to example is LMAX. I think I remember a talk where the devs said they were pulling 6M orders per second, and ofc the stock market has an aggressive power law. If you design around contention, you can still push silly high perf (as you've shown).
FWIW I think we both agree that Postgres is not the best DB for this either :P
While TigerBeetle way is very interesting I find lack of multicore processing support (or any kind of horizontal scaling) a blocker in terms real world deployment. It is just too risky as there is a hard limit to scalability and while it might look it is high enough for foreseeable future, what am I supposed to do once I reach this limit? Financial database has to be planned with at least 15-20 years of growth in min…
sorry if the question seems dumb, but are the clustering options not good for scaling?
Earlier quoted context omitted.
TigerBeetle doesn't shard either.
Yes, sharding would kill performance under contention, which characterizes many OLTP workloads (e.g. top ten bestseller list on Black Friday, super stocks like NVIDIA, the big 4 banks on a switch, PhonePe/Google Pay on UPI etc)
Earlier quoted context omitted.
I don't think a post on a VC blog of all places should be considered "journalism"
You're nitpicking the term "journalism" here, but even in casual conversation if a friend went on and on about how great a company was and then I later found out that they: * Got paid a referral fee if I signed up * Owned shares in the company * Even was roommates with the founders/CEO but failed to mention it I would trust that person less going forward. If you want to be perceived as trustworthy, then you shouldn't…