Hacker News: denchickhttps://news.ycombinator.com/user?id=denchickHacker News RSShttps://hnrss.org/hnrss v2.1.1Sat, 04 Jul 2026 17:07:36 +0000<![CDATA[New comment by denchick in "Show HN: IceGate – Observability data lake engine"]]>> 3x faster than nearest competitors

Wow, that's awesome! Do you have any public benchmarks?

]]>Mon, 13 Apr 2026 15:33:55 +0000https://news.ycombinator.com/item?id=47753519denchickhttps://news.ycombinator.com/item?id=47753519https://news.ycombinator.com/item?id=47753519<![CDATA[New comment by denchick in "Show HN: IceGate – Observability data lake engine"]]>How do you achieve fault tolerant?

]]>Mon, 13 Apr 2026 15:31:22 +0000https://news.ycombinator.com/item?id=47753475denchickhttps://news.ycombinator.com/item?id=47753475https://news.ycombinator.com/item?id=47753475<![CDATA[New comment by denchick in "Hacking the Postgres wire protocol"]]>> I am wondering, why it took so long for something like this to happen for Postgres

We were thinking about adding PostgreSQL support to Vitess several years ago. However, we realized that it would be more efficient if each tool was focused on a specific task.

https://github.com/vitessio/vitess/issues/7084#issuecomment-...

]]>Wed, 16 Apr 2025 08:40:18 +0000https://news.ycombinator.com/item?id=43703010denchickhttps://news.ycombinator.com/item?id=43703010https://news.ycombinator.com/item?id=43703010<![CDATA[SPQR 2.0 Released]]>Article URL: https://github.com/pg-sharding/spqr/releases/tag/2.0

Comments URL: https://news.ycombinator.com/item?id=41850383

Points: 3

# Comments: 0

]]>Tue, 15 Oct 2024 16:38:55 +0000https://github.com/pg-sharding/spqr/releases/tag/2.0denchickhttps://news.ycombinator.com/item?id=41850383https://news.ycombinator.com/item?id=41850383<![CDATA[SPQR 1.5.0: a production-ready system for horizontal scaling of PostgreSQL]]>Article URL: https://github.com/pg-sharding/spqr/discussions/724

Comments URL: https://news.ycombinator.com/item?id=41007281

Points: 12

# Comments: 4

]]>Fri, 19 Jul 2024 15:07:44 +0000https://github.com/pg-sharding/spqr/discussions/724denchickhttps://news.ycombinator.com/item?id=41007281https://news.ycombinator.com/item?id=41007281<![CDATA[SPQR: Scaling PostgreSQL via Sharding]]>Article URL: https://pg-shardingspqr.mintlify.app/welcome/index

Comments URL: https://news.ycombinator.com/item?id=40883217

Points: 14

# Comments: 4

]]>Fri, 05 Jul 2024 14:41:21 +0000https://pg-shardingspqr.mintlify.app/welcome/indexdenchickhttps://news.ycombinator.com/item?id=40883217https://news.ycombinator.com/item?id=40883217<![CDATA[New comment by denchick in "SPQR 1.3.0: a production-ready system for horizontal scaling of PostgreSQL"]]>> High concurrency can become a problem due to the 1 process per connection architecture.

If I understand correctly what you mean, then this is no longer a problem. You will simply need to use a connection pool, such as Odyssey or PgBouncer. Even SPQR has its own pool of connections for each shard.

]]>Mon, 25 Mar 2024 15:47:59 +0000https://news.ycombinator.com/item?id=39817819denchickhttps://news.ycombinator.com/item?id=39817819https://news.ycombinator.com/item?id=39817819<![CDATA[New comment by denchick in "SPQR 1.3.0: a production-ready system for horizontal scaling of PostgreSQL"]]>https://github.com/pg-sharding/spqr/issues/571

]]>Mon, 25 Mar 2024 14:50:26 +0000https://news.ycombinator.com/item?id=39817030denchickhttps://news.ycombinator.com/item?id=39817030https://news.ycombinator.com/item?id=39817030<![CDATA[SPQR 1.3.0: a production-ready system for horizontal scaling of PostgreSQL]]>Article URL: https://github.com/pg-sharding/spqr/discussions/569

Comments URL: https://news.ycombinator.com/item?id=39814877

Points: 185

# Comments: 71

]]>Mon, 25 Mar 2024 11:24:39 +0000https://github.com/pg-sharding/spqr/discussions/569denchickhttps://news.ycombinator.com/item?id=39814877https://news.ycombinator.com/item?id=39814877