What Does a Database for SSDs Look Like? • Hacker News Board

Re: What Does a Database for SSDs Look Like?

#51

Post by OptionOfT » Sat, Dec 20, 2025, 2:19 PM UTC

threeducks wrote: post #15

crazygringo wrote: post #12

Earlier quoted context omitted.

Can you clarify? I thought a major benefit of SSDs is that there isn't any difference between sequential and random access. There's no physical head that needs to move. Edit: thank you for all the answers -- very educational, TIL!

Lets take the Samsung 9100 Pro M.2 as an example. It has a sequential read rate of ~6700 MB/s and a 4k random read rate of ~80 MB/s: https://i.imgur.com/t5scCa3.png https://ssd.userbenchmark.com/ (click on the orange double arrow to view additional columns) That is a latency of about 50 µs for a random read, compared to 4-5 ms latency for HDDs.

At the 4K random reads impacted by the fact that you still cannot switch Samsung SSDs to 4K native clusters?

Re: What Does a Database for SSDs Look Like?

#52

Post by amluto » Sat, Dec 20, 2025, 2:21 PM UTC

cornholio wrote: post #49

You know you need to be careful when an Amazon engineer will argue for a database architecture that fully leverages (and makes you dependent of) the strengths of their employer's product. In particular: > Commit-to-disk on a single system is both unnecessary (because we can replicate across storage on multiple systems) and inadequate (because we don’t want to lose writes even if a single system fails). This is surely…

Skipping flushing the local disk seems rather silly to me:

- A modern high end SSD commits faster than the one way time to anywhere much farther than a few miles away. (Do the math. A few tens of microseconds specified write latency is pretty common. NVDIMMs (a sadly dying technology) can do even better. The speed of light is only so fast.

- Unfortunate local correlated failures happen. IMO it’s quite nice to be able to boot up your machine / rack / datacenters and have your data there.

- Not everyone runs something on the scale of S3 or EBS. Those systems are awesome, but they are (a) exceedingly complex and (b) really very slow compared to SSDs. If I’m going to run an active/standby or active/active system with, say, two locations, I will flush to disk in both locations.

Re: What Does a Database for SSDs Look Like?

#53

Post by Rakshath_1 » Sat, Dec 20, 2025, 2:36 PM UTC

[dead]

Re: What Does a Database for SSDs Look Like?

#54

Post by Rakshath_1 » Sat, Dec 20, 2025, 2:37 PM UTC

[dead]

Re: What Does a Database for SSDs Look Like?

#55

Post by ritcgab » Sat, Dec 20, 2025, 2:38 PM UTC

SSDs are more of a black box per se. FTL adds another layer of indirection and they are mostly proprietary and vendor-specific. So the performance of SSDs are not generalizable.

Re: What Does a Database for SSDs Look Like?

#56

Post by Tostino » Sat, Dec 20, 2025, 2:39 PM UTC

Sesse__ wrote: post #25

throw0101a wrote: post #23

Earlier quoted context omitted.

> A write-ahead log isn't a performance tool to batch changes, it's a tool to get durability of random writes. ¿Por qué no los dos?

Because it is in addition to your writes, not instead of them. That's what “ahead” points to.

Look up how "checkpointing" works in Postgres.

Re: What Does a Database for SSDs Look Like?

#57

Post by exabrial » Sat, Dec 20, 2025, 2:39 PM UTC

> Commit-to-disk on a single system is both unnecessary

If you believe this, then what you want already exists. For example: MySQL has in memory tables, but also this design pretty much sounds like NDB.

I don’t think I’d build a database the way they are describing for anything serious. Maybe a social network or other unimportant app where the consequences of losing data aren’t really a big deal.

Re: What Does a Database for SSDs Look Like?

#58

Post by Havoc » Sat, Dec 20, 2025, 2:43 PM UTC

I'm a little bit surprised enterprise isn't sticking to optane for this. It's EoL tech at this point, but it'll still smoke top of the line nvmes for small Q1 which I'd think you'd want for some databases.

Re: What Does a Database for SSDs Look Like?

#59

Post by dbzero » Sat, Dec 20, 2025, 2:45 PM UTC

Please give a try to dbzero. It eliminates the database from the developer's stack completely - by replacing a database with the DISTIC memory model (durable, infinite, shared, transactional, isolated, composable). It's build for the SSD/NVME drive era.

Re: What Does a Database for SSDs Look Like?

#60

Post by ghqqwwee » Sat, Dec 20, 2025, 2:46 PM UTC

I’m a bit disappointed the article doesn’t mention Aerospike. It’s not a rdbms but a kvdb commonly used in adtech, and extremely performant on that use case. Anyway, it’s actually designed for ssds, which makes it possible to persist all writes even when the nic is saturated with write operations. Of course the aggregated bandwidth of the attached ssd hardware needs to be faster than the throughput of the nic, but not much, there’s very little overhead in the software.