News for hackers. Stuff that matters.
Re:Show HN: BemiDB – Postgres read replica optimized for ana... by potamic on Thursday November 07, 2024 @11:29PM (#42084141)
Would love the authors to pitch in with their use cases, but I think most people simply do not need sub millisecond analytics. This is mostly replacing typical spark pipelines where you're okay with sub second latencies.

S3 is the cheapest, fully managed storage you can get that can scale infinitely. When you're already archiving to S3, doubling it for analytics saves cost and simplifies data management.

Re:Show HN: BemiDB – Postgres read replica optimized for ana... by hipadev23 on Friday November 08, 2024 @03:24PM (#42090176)
Sub-millisecond? Literally nobody in large data analysis is doing that. Can you cite some sources or show me what sort of setups (with any DB tech) that you're able to run meaningful queries on S3 sources with even sub-second latency?
Re:Show HN: BemiDB – Postgres read replica optimized for ana... by broner on Saturday November 09, 2024 @10:44AM (#42094999)
I'm doing this with clickhouse querying parquet files on S3 from an EC2 instance in the same region as the S3 bucket (yes DuckDB pretty similar). S3 time to first byte within AWS is 50ms and I get close to saturating an big EC2 instance's 100Gb link doing reads. For OLTP type queries fetching under 1 MB you'll see ~4 round trips + transfer time of compressed data so 150-200 ms latency.
Re:Show HN: BemiDB – Postgres read replica optimized for ana... by hipadev23 on Saturday November 09, 2024 @01:23PM (#42095960)
Are you using s3 local cache? Do you have heavy writes? What type of s3 disk type, if any, are you using? (s3, s3_plain, s3_plain_rewritable)? Or are you just using the s3 functions.

Clickhouse is amazing but I still struggle getting it working efficiently on s3, especially writes.

Re:Show HN: BemiDB – Postgres read replica optimized for ana... by broner on Saturday November 09, 2024 @03:58PM (#42096860)
My workload is 100% read. Querying zstd parquet on s3 standard. Neither clickhouse nor duckdb has a great s3 driver, which is why smart people like https://www.boilingdata.com/ wrote their own. I compared a handful of queries and found DuckDB makes a lot of round trips and Clickhouse takes the opposite approach and just reads the entire parquet file.