tbarbugli

After fighting crash after crash with pgcopydb v17 and v18 I decided to bite the bullet and write my own in Golang.

I picked Golang because most issues with pgcopydb were related to concurrency bugs and memory leaks. There is nothing in this tool that requires C, Golang is totally fine and comes with a good concurrency built-in and a garbage collector.

A few more notable improvements:

- I use binary format instead wal2json - Optional control plane with web interface - CDC replay runs concurrently (partition by fk)

At getstream.io we ended up running Github Actions on Hetzner. The end-result is 4x faster builds for 3x less $$$.

Running workers ourselves was the last resort, we tried everything else but it was impossible to get fast (and consistent) build times otherwise.

In a way we are now going to get charged for Github's poor execution on Actions.

> anyone can see what URLs you are visiting

this is not correct with HTTPS (query params are not part of the plain text)

ofc it depends where you would hire, for me (NL) its above 100x more efficient

I agree, only reason I read the project readme was to see the drop-in explainer.

Very misleading title

searching for running shoes returns a mix of brands and shoe models

Plenty of engineers on the market can work professionally in C. Only a small amount of people can write Cobol (or is willing to given that is almost useless). That alone is a good reason to consider Cobol a legacy language and throw away a codebase written in Cobol.

> At Compose, every WebSocket message starts with a fixed 2-byte type prefix for categorizing messages.

some of the complexity is self-inflected by ignoring KISS principle

In my experience, only Swift has a generator that produces good-quality code. Ironically, it’s developed by Apple.

The list of supported commands looks quite impressive https://kvrocks.apache.org/docs/supported-commands#script-co...

Using DynamoDB in 2025 is such a weird proposition. Horrible dev experience, no decent clients/libs, complex pricing, weird scaling in/out mechanism, slow, it only works well for well defined use-cases.

Google is not winning on cloud, AWS is winning and MS gaining ground.

> Use Postgres for Fulltext Search instead of Elastic

pg fulltext search is very limited and user unfriendly, not a great suggestion here

Ideally it does not run on the awful EBS storage (slow and expensive).

Possibly because they capture the video from xvfb or similar (they run a headless browser to capture the video) so at that point the decoding already happened (webrtc?)

Makes you wonder why there were no plane hijacks since 9/11. TSA does not seem a credible prevention mechanism given how easy it is to go around it.

Nice article which matches my experience when it comes to optimizing for performance: Linux defaults are never good defaults and you don't need webscale or anything before you get bitten by them.

To make a few examples: on many distributions you get 1024 as the file limits, 4KB of shared memory (shmall) and Nagle's algorithm is enabled by default.

Another thing that we noticed at work (shameless plug to getstream.io) when it comes to tail latency for APIs / HTTP services:

- TLS over HTTP is annoyingly slow (too many roundtrips)

- Having edge nodes / POPs close to end-users greatly improves tail latency (and reduces latency related errors). This works incredibly well for simple relays (the "weak" link has lower latency)

- QUIC is awesome

TL;DR it is a job

hosted on Vercel and Github...

isn't China producing more electricity with solar than all other countries combined (with solar)?

io2 is generally better than io1, one advantage is that you can scale storage size and IOPS independently. That being said, RDS with io2 is still worse than an ec2 instance with nvme (a lot worse)

RDS is such a depressing database option. It does not matter how much money you throw at it, its performance will always be limited by the awful disk IOPS. Luckily these days you can easily run PG on EC2 (or simply use CRDB).

Weird for Heroku to ignore this huge efficiency opportunity.

well, they shut this down probably because they cannot afford to keep a product that bring little revenue. I never heard of AWS retiring a product (I am excluding ancient stuff like VPC classic and SimpleDB, both had an upgrade path to something superior)

it increases the cost for the attacker, forging ID is expensive and against the law. It also leaves behind additional evidence that might be useful to investigators

I think its around 1TB a day, but indeed still very small.

we wrap all errors with a stack.Wrap function that adds stacktrace to the error. This allows us to add stacktraces to logs and err reporting tools like Sentry. Huge time saver

you only do it when there is a not nil err + being able to have a stacktrace is worth more than whatever it costs is CPU

Citus seems incredibly close to what they built, I wonder why they did not use it