51–60 of 228 posts
> 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).
> 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).
I like to write assertions that aren't always easy to check. Like asserting that a list is sorted.
However, several factors have to be taken into account regarding performance impact when they get cleverly written, thus in manys cases they can only be fully turned on during debug builds.
Earlier quoted context omitted.
Joran from TigerBeetle! Without much sweat for general purpose workloads. But transaction processing tends to have power law contention that kills SQL row locks (cf. Amdahl’s Law). We put a contention calculator on our homepage to show the theoretical best case limits and they’re lower than one might think: https://tigerbeetle.com/#general-purpose-databases-have-an-o...
>Traditional SQL databases hold locks across the network; under Amdahl's Law, even modest contention caps write throughput at ≈100–1,000 TPS In fact large real world systems are not limited to 100-1000 TPS, or even 10 kTPS as the calculator tries to suggest. That's not because Amdahl's law is wrong, the numbers you're plugging in are just wildly off, so the conclusions are equally nonsensical. There might be some spe…
> Without much sweat for general purpose workloads.
All of these apply to FoundationDB as well. - Slow code writing. - DST - No dependencies - Distributed by default in prod - Clock fault tolerance with optimistic locking - Jepsen claimed that FDB has more rigorous testing than they could do. - New programming language, Flow, for testing. You probably could solve the same problems with FDB, but TigerBeetle I imagine is more optimized for its use case (I would hope...)…
We were considering TigerBeetle, but found blockers: * We use Cloudflare Workers. TigerBeetle client app is not supported. It might work using Cloudflare Containers, but then the reason we use Cloudflare is for the Workers. --> https://github.com/tigerbeetle/tigerbeetle/issues/3177 * TigerBeetle doesn't support any auth. It means the containing server (e.g. a VPS) must restrict by IP. Problem is, serverless doesn't h…
But Cloudflare Workers or AWS Lambda setup would not work anyway with any db? * spawning 1000 workers all opening a connection to a db, * solved by service/proxy in front of db, * proxy knows how to reach db anyway, let's do private network and not care about auth
> And yet some of the most popular OLTP databases in the world today are still highly dependent on a single node architecture. Which databases? SQLite is the one I can think of, but it's designed for that use-case. Others start as single node but will replicate to other nodes, either as master-slave or master-master.
I am quite sure Oracle and MS SQL server do just fine in multi-node cluster based architectures, but maybe that isn't their target audience.
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?
Earlier quoted context omitted.
That sounds easy to check. Can you expand on this, because I don't understand.
its easy as in "simple to implement and execute" but not cheap, because it may require scanning large amounts of memory. You have to visit every list entry. Whats trivial for a very small list, may be a no-go for gigabyte-sized lists.
> 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.
True. The older databases run very well even on hardware which was far less powerful than what is available now.