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.

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).