121–130 of 228 posts
Earlier quoted context omitted.
DNS still runs strong and it was ~~designed~~ released* in the November 1983. It still holds up basically whole of internet. in most cases SQL is good enough for 90% of workloads.
What would DNS look like if it were released in 2025?
config defined in YAML.
What does TigerBeetle stand on the CAP theorem? Sounds like it's AP?
cf. Durability and the Art of Consensus: https://www.youtube.com/watch?v=tRgvaqpQPwE
> They keep assertions enabled in production. Never understood why we turn those off. An assert failing in prod is an assert that I desperately want to know about. (That "never understood" was rhetorical).
But nowadays an extra comparison is no biggie, especially if the compiler can hint at which way it's likely to go.
> In less than a decade, the world has become at least three orders of magnitude more transactional. And yet the SQL databases we still use to power this are 20-30 years old. Can they hold up? Errr yes. Without much sweat really. Just because something started ~30 years ago doesn't mean it hasn't updated with the times, and doesn't mean it was built on bad foundations.
DNS still runs strong and it was ~~designed~~ released* in the November 1983. It still holds up basically whole of internet. in most cases SQL is good enough for 90% of workloads.
It says: “TigerBeetle uses a single core by design and uses a single leader node to process events. Adding more nodes can therefore increase reliability, but not throughput.”
How does this work with multi-region? Does this mean that regardless of where in the world your users might live, they need to make a request to the leader node for a write to occur?
Is distribution purely for redundancy?
Earlier quoted context omitted.
DNS still runs strong and it was ~~designed~~ released* in the November 1983. It still holds up basically whole of internet. in most cases SQL is good enough for 90% of workloads.
What would DNS look like if it were released in 2025?
https://softwareengineeringdaily.com/2024/09/12/building-a-f...
Earlier quoted context omitted.
Yeah, SQL is not the issue. At least not mostly. The relational model has shown itself to be exactly the flexible and powerful model that Codd said it was, even in its relatively-debased from in SQL. In fact the potential of it as a universal and flexible data model that abstracts away storage still remains to be fully unlocked. Now as for existing SQL databases, yes, many of them were built on foundational assumptio…
> Throwing out SQL is not really the recipe for "performance" We've discovered hacks to work around the limitations of SQL, so you can maintain performance with sufficient hackiness, but you have to give up "purity" to get there. Worse is better applies, I suppose, but if we were starting over today the design would be very different. Throwing out SQL isn't strictly required, but like Rust isn't strictly required whe…
SQL was the first serious attempt to translate this into a working system, and it's full of warts, but the underlying model it is reaching towards retains its elegance.
But most importantly the principle of not tying the structure of data to its storage model is absolutely key. Not least because we can iteratively and flexibly improve the storage model over time, and not be stuck with decisions that tie us to one particular structure which is the problem that 1960s "network" and "hierarchical" databases (and modern day "key value" or "NoSQL" databases) cause.
Because I'm sure other people will ask - no, it does not support SQL.
Transactions atomically process one or more Transfers, keeping Account balances correct. Accounts are also records, their core fields (debits_posted, credits_posted, etc).
This gives a good idea of what TigerBeetle might be good for and what it might not be. For anything where latency/throughput and accuracy really, really matters, it could be worth the effort to make your problem fit.