A database person meets a format with the following specs: (1) read-optimized format, (2) designed to work without regular filesystem, only requiring object storage, (3) does not need central coordinator processes.
They are very angry that this format (1) is not write-optimized, (2) has overheads because it limits itself to object storage and does not take advantage of regular filesystems, (3) does not use central coordinator processes.
I understand the author has "been building databases, database engines and writing SQL for over 35 years now", but they are completely missing the point when they say "Fact 1: Object Storage sucks!".
Yes, it sucks for database developer, but it is so great from operations perspective! Scaling, backing up, verifying, sharding, distributed access - you name it, it's way easier for object storage. Practically every application (except databases and log) would be easier if file updates were atomic, and whole-file-only. So it's not surprising that some people choose to use it as a database.
They are very angry that this format (1) is not write-optimized, (2) has overheads because it limits itself to object storage and does not take advantage of regular filesystems, (3) does not use central coordinator processes.
I understand the author has "been building databases, database engines and writing SQL for over 35 years now", but they are completely missing the point when they say "Fact 1: Object Storage sucks!".
Yes, it sucks for database developer, but it is so great from operations perspective! Scaling, backing up, verifying, sharding, distributed access - you name it, it's way easier for object storage. Practically every application (except databases and log) would be easier if file updates were atomic, and whole-file-only. So it's not surprising that some people choose to use it as a database.