The whole point is to force the cloud providers to go through a contract negotiation for licensing rather than keep the door open for them. Nothing prevents the parent project from specially licensing to individual parties.

> which use a cloud managed DB solution (GCP CloudSQL PostgreSQL) it means something like this would never be available

That's up to GCP then. I'm sure OP would be willing to license pgrust to them for an appropriate price.

what exactly are your concern of using agpl db server? It doesn't force you to make rest of your system agpl.

>we would be happy to dual-license under a commercial license

Why would AGPL force you to open source your app? Unless you literally compile your app with pgrust by modifying the pgrust source code, you're safe. Clients aren't bound by the AGPL because they aren't derived works.

License policies are made by lawyers not by programmers. And their competition will be in the exact same boat (different lawyers though). AGPL is so toxic that it tends to be checked for during M&A processes so even if the current batch of lawyers is ok with it there is a chance that a later batch of lawyers is not. Given that the target audience for this project is the larger companies you are going to end up with a very nice project and zero actual users or you will end up with AWS et all stealing your work. Databases are very hard to do successfully commercially, at a minimum you should dual license them (AGPL for 'home' use and commercial licensing for parties that will want to buy the upside but they'll demand support and other stuff besides).

Its 300x faster for certain tests. I could pretty easily craft tests that do this on two different systems. The author mentioned this when they talked about being able to fit an entire ResultSet into memory. That's the real trick with performance. Very few workloads are CPU bound anymore (linear algebra on the CPU for example). Almost all workloads are memory bound. So its all about moving data from memory to network, back to memory and back to network, over and over again through your microservices or DBs. If the entire working set can fit in memory, you get at least a 10x performance boost. If you have to keep even a part of the working set on disk, its a huge performance loss. And the larger fraction of the working set on disk, the worse the performance loss.

PS Learn how DBs do joins for more information. Specifically the differences between hash joins, merge joins and nested loop joins. They are basically fancy ways to page part of your working set to disk at huge performance penalties.

PPS As memory gets more expensive, these techniques get more valuable. When it gets cheap, they lose value.

They could simply spend a few months and a few million tokens and get their own port, no?

I doubt even 30000x faster would prompt a policy change.

So, keyword 'rational', I'm not sure any sufficiently large company is a rational actor.

Yes, at [tech corp dayjob], any dependency is likely to be banned for arbitrary reasons if you bring it to the attention of the wrong people. It doesn't have to go against any of our policies e.g. don't mention anything with GPL in the name around the "risk" people. In fact, do not ever talk to the "risk" people and hope they don't talk to you.

Latest news: Apparently, devtools are a legal risk. Basic reverse-engineering of client-side JS is now banned.

The delusions really seem to scale with headcount.

we have not once claimed postgres is under our control. i don't think you understand how open source works but thats ok.

official projects are usually run by sensible people who want to do things and aren't leading with ideology.

We're literally talking about an "X but in Rust" project already...

What's the reason for it? Does not make a lot of sense to keep all the commits elsewhere

What do we mean by "easy to claim"? It is written by AI. The 6000 commits are by Claude.