hasyimibhar

It’s not pessimistic at all. Look at the advances in math thanks to hundreds years of pursuit to prove Fermat’s Last Theorem before Andrew Wiles finally did it in the 90s. You will not get that with LLM. That’s what mathematicians are mourning over.

I've never touched my ISP-provided router. But maybe it's just how it works in my country (Malaysia), we pretty much only have 1 ISP with monopoly, so maybe that helps.

Queues are for actions (do this), K2/event streams are for events (this happened).

It’s built for Cloudflare ecosystem, IMO using K2 on its own doesn’t make sense. I’ve worked with a startup that uses Cloudflare for everything except for Kafka. If K2 were to exist back then, I’m pretty sure they would have used it.

The homepage shows an example of an agent accidentally dropping a table.

1. This is such an insane example, I don't get why would you give agents write access to your production db in the first place. Are people really doing this? I don't even have production connection urls on my laptop. Any manual statements executed against the db must be treated as a war-room situation with at least another engineer reviewing your SQL before you execute it.

2. Dropping the table could have easily caused writes to fail. Most likely there is no way to recover these writes (especially if it's from user requests), so it could have lead to loss of data. Reversing the table drop doesn't fix this issue.

Having worked at a large company that misuses feature flag service for everything, here are some examples why you shouldn’t:

- one team uses feature flag for product gating. Feature flag service goes down. Users temporarily got locked out of the features they paid for.

- one team uses feature flag for dynamic pricing by leveraging targeting rules (how hard is it to write a bunch of if else in code?). It’s evaluated against all users, even if they are not active (for analysis reasons). Feature flag service charges by MAU. We have millions of users. Our feature flag service bill is now 6 digits per year.

- one team uses feature flag as literal json store instead of a proper db (god knows why). Someone updated the value but the “schema” is wrong. Shit breaks.

> Examples? Ok -> Let us look at data storage.

> They got D1 (SQLite serverless), Durable Objects with their own SQLite, KV, R2, Queues, and Hyperdrive to speed up external Postgres or MySQL.

Maybe it's just me, but I don't see this as confusing:

- D1 is SQLite on cloud, their go-to relational database

- Durable object is the cousin of durable execution (via actor model instead of saga)

- KV is for caching like Redis (sub-ms read latency)

- R2 is S3, R2 SQL is Iceberg + Athena (for OLAP queries)

- Queue is SQS

- Hyperdrive is bridge to allow CF worker to use native Postgres/MySQL driver (since v8 isolate cannot maintain persistent connection)

I've built some stuff on top of CF, and the data ecosystem is actually useful.

DMS is so unreliable though.

I’m waiting for Cloudflare R2 to eventually support mirroring Postgres into R2 catalog. It seems like a nice fit because they already have R2 SQL.

Yes I’m not suggesting to do this inside Postgres. I’m hoping that a Postgres provider can provide this mirroring capability out of the box, similar to how they provide a connection-pooled endpoint out of the box so I don’t have to self-host pgBouncer. I just want to be able to check a box somewhere and have a table in Postgres automatically mirrored to Iceberg, with guarantee that no data is lost. They can charge more for it, I will gladly pay.

It's interesting to watch how different companies that offer both Postgres and warehousing solution under 1 roof approach the same problem:

- ClickHouse focuses on traditional CDC (ClickPipes) and just make it blazingly fast

- Databricks leans on their unified storage architecture (LTAP) to avoid copying data (though you can argue there is still a copy in the cache)

- Snowflake uses a data mirroring CDC as extension so it runs directly on Postgres

I'm still waiting for a Postgres provider to just let me mirror data directly to Iceberg, so I can plug in my own stateless query engine.

> Almost always they end up setting up a separate system such as Clickhouse and replicating the data between the two systems. Now they can have one system that's Postgres-compatible, and it's faster than either of the original systems.

I can see the appeal for pgrust for smaller teams who need analytics, and don't want to deal with having to ETL to something like ClickHouse. But beyond a certain complexity, replicating your data to a warehouse or lakehouse _is_ the right approach and more scalable for several reasons:

- Analytics tend to be centralized, i.e. you want data from several Postgres databases spread across multiple teams to be replicated into 1 place, so people can start joining data across the entire business

- Analytics tend to fall under a different team ownership with their own set of non-technical requirements (e.g. data governance)

- Lakehouse architecture (Iceberg + [insert query engine]) is more scalable in terms of cost

- In some cases, you want to be able to swap different query engines depending on the use case, e.g. use PuppyGraph to query your data in Iceberg for fraud analysis

Sorry but that is not pixel art.