Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
saisrirampur
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
61.
▲
We scaled PgBouncer to 4x throughput
(clickhouse.com)
241 points
by
saisrirampur
3mo ago
|
61 comments
62.
▲
Pg_re2: Postgres extension for fast, RE2-powered regular expressions in Postgres
(clickhouse.com)
3 points
by
saisrirampur
3mo ago
|
0 comments
63.
▲
We Scaled PgBouncer to 4× Higher Throughput
(clickhouse.com)
2 points
by
saisrirampur
3mo ago
|
0 comments
64.
▲
AI needs the best-of-breed data stack: Postgres and ClickHouse
(clickhouse.com)
1 points
by
saisrirampur
3mo ago
|
0 comments
65.
▲
We Scaled PgBouncer to 4× Higher Throughput
(clickhouse.com)
4 points
by
saisrirampur
3mo ago
|
1 comments
66.
▲
Pg_stat_ch: PostgreSQL Query Telemetry Exporter to ClickHouse
(github.com)
2 points
by
saisrirampur
4mo ago
|
0 comments
67.
▲
We Scaled PgBouncer to 4× Higher Throughput
(clickhouse.com)
3 points
by
saisrirampur
4mo ago
|
0 comments
68.
▲
by
saisrirampur
4mo ago
Oh no, I did read the blog. Not throwing shade at anyone here—the blog is great. It just doesn’t provide real-world evidence, and it opens up a bunch of technical questions that I’m trying to understand. that’s exactly what HN is for. :)
69.
▲
by
saisrirampur
4mo ago
;) sounding good on paper vs how it works in practice (supporting demanding real-time OLTP/OLAP workloads) are completely different ball games. Separately, I understand taking care of it at storage level, but still don’t get “unifying
70.
▲
by
saisrirampur
4mo ago
Exactly! Why unifying storage, which opens up a can of trade-offs.
71.
▲
by
saisrirampur
4mo ago
Taxing Postgres is one thing, which can be overcome with ways like using standbys. There could other more native ways (than unifying storage), which you’ll hear about in a few weeks. Also I don’t fully agree on logical replication taxing Po
72.
▲
by
saisrirampur
4mo ago
But why? I’m skeptical of the idea of unifying storage just because it sounds “elegant” or “cool”. It’s not obvious to me how a single storage engine can compete with purpose-built OLTP and OLAP systems like Postgres and ClickHouse, without
73.
▲
Scaling PgBouncer Beyond a Single CPU Core
(clickhouse.com)
1 points
by
saisrirampur
4mo ago
|
0 comments
74.
▲
Scaling a 1.59 quadrillion-row logging system across three clouds
(clickhouse.com)
2 points
by
saisrirampur
4mo ago
|
0 comments
75.
▲
What are Forward Deployed Engineers, and why are they so in demand?
(newsletter.pragmaticengineer.com)
4 points
by
saisrirampur
4mo ago
|
0 comments
76.
▲
PostgreSQL and ClickHouse as the Open Source unified data stack
(clickhouse.com)
1 points
by
saisrirampur
4mo ago
|
0 comments
77.
▲
by
saisrirampur
4mo ago
++ We’re big Go fans, most of PeerDB is written in Go: https://github.com/PeerDB-io/peerdb The importance of optimizing (resource) margins and having predictable memory usage increases significantly in the DBaaS/P
78.
▲
WAL-RUS: a Rust Rewrite of WAL-G for PostgreSQL Backups
(clickhouse.com)
132 points
by
saisrirampur
4mo ago
|
21 comments
79.
▲
We Rewrote WAL-G for Postgres Backups in Rust: Meet WAL-RUS
(clickhouse.com)
3 points
by
saisrirampur
4mo ago
|
0 comments
80.
▲
Why everyone is talking about real-time analytics
(clickhouse.com)
4 points
by
saisrirampur
4mo ago
|
0 comments
81.
▲
by
saisrirampur
4mo ago
It could be the other way round too. ;) We just limited the number of Postgres providers in the first batch. May add you in the next and might ping you before sharing it in public, just to make you sure you are aligned and like them.
82.
▲
by
saisrirampur
4mo ago
Ack, your insight is very interesting. Back at Citus/Microsoft, we typically saw around a 30% performance drop with synchronous replication on EBS-backed Postgres. I’d expect something in that ballpark for RDS and Crunchy as well. For
83.
▲
by
saisrirampur
4mo ago
It wasn’t left out on purpose, it was just prioritization, we chose 5 that most commonly came up. Please feel free to submit a PR, it should be pretty straightforward.
84.
▲
by
saisrirampur
4mo ago
Good feedback, we will aim to include them in the future.
85.
▲
by
saisrirampur
4mo ago
Ack on most points i.e. duration, scale factor (data size) and pricing. We will try incorporating these in the next iterations. In regards to HA, partly agreed. We are working on adding HA setup as we speak, should be released soon. However
86.
▲
by
saisrirampur
4mo ago
Yes, you absolutely can. It takes 15 mins to run the benchmark amd get results.
87.
▲
PostgresBench: A Reproducible Benchmark for Postgres Services
(clickhouse.com)
113 points
by
saisrirampur
4mo ago
|
24 comments
88.
▲
by
saisrirampur
4mo ago
You should check this message that talks about everything we are doing to make adoption of ClickHouse with Postgres easy. It captures all the tools we’ve released and are actively working on. https://news.ycombinator.com/ite
89.
▲
by
saisrirampur
4mo ago
We at PeerDB/CickPipes tried to make that mirroring as frictionless as possible. It is validated at scale across 1000s of customer moving over half a PB of a data per month from Postgres to ClickHouse. You should give it a shot and you
90.
▲
by
saisrirampur
4mo ago
Sai from ClickHouse here. Totally with you here, ClickHouse isn't a replacement for Postgres. Most use-cases are co-existence - Postgres for OLTP and ClickHouse for OLAP, basically right tool for the right job situation. Both are purpo
More ›