| ▲ | appplication 5 hours ago |
| Oh bummer. I was really excited about pgrust but AGPL is a dealbreaker. Not for me personally, but it will never see wide adoption because it’s a banned license in most corporate environments. Lack of path to wide adoption means it’s dead in the water. It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such a way they’ll never use it? This also hard blocks upstreaming any beneficial features into core Postgres. |
|
| ▲ | guenthert 4 hours ago | parent | next [-] |
| If it is indeed 300* faster, I'm sure more rational corporations will rethink their license policy or be left in the dust. |
| |
| ▲ | jacquesm 3 hours ago | parent | next [-] | | 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). | | |
| ▲ | hunterpayne 3 hours ago | parent [-] | | This is the case when you have your own datacenter. This isn't as big a problem in the cloud. There are ways to write licenses that prevent cloud providers from stealing while allowing customers to use the software and being required to pay for it. The problem with the AGPL has to with its viral nature, not its provisions to prevent cloud vendor theft. |
| |
| ▲ | hunterpayne 3 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | xyzzy_plugh 4 hours ago | parent | prev | next [-] | | 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. | | |
| ▲ | superb_dev 3 hours ago | parent | next [-] | | Are you suggesting the AI just rewrites the whole thing under a different license? There’s no way that’s not more dicey than the AGPL license. | | |
| ▲ | jacquesm 3 hours ago | parent [-] | | That's exactly what they did here, I don't see the difference. | | |
| ▲ | hunterpayne 3 hours ago | parent | next [-] | | This is the difference. This guy took an existing source base, had Claude find specific bugs, then had Claude fix a specific bug which was then reviewed by a person. We also don't know if these changes introduce new problems yet. You are suggesting letting Claude write an entirely new source base. That's light-years away from what happened here. | |
| ▲ | yifanl 3 hours ago | parent | prev [-] | | They did it on permissively licensed code would be the difference. |
|
| |
| ▲ | hunterpayne 3 hours ago | parent | prev [-] | | No. This is system code. You let an LLM loose on it, it probably fixed 20 bugs and introduces 200 more plus 5 different performance regressions. In all fairness, your average app programmer would have the same problems. That's why it takes so long to learn to be a system programmer and why it takes so long to do anything on a systems source base. For reference, systems are OSes, DBs and compilers (although compilers are very different in many ways). Also, you can successfully sell a systems project that is only 10% faster. 30000x faster and they are throwing illegal and debauched things through your window to get access to your improvements. | | |
| ▲ | skinfaxi 2 hours ago | parent [-] | | > No. This is system code. You let an LLM loose on it, it probably fixed 20 bugs and introduces 200 more plus 5 different performance regressions. What does it being system code have to do with anything? | | |
| ▲ | hunterpayne 6 minutes ago | parent [-] | | The brittleness and difficult of writing the code. The extra complexity. The cost of bugs. And ease of creating performance degradations. If you are even asking that question, you probably don't have the experience to even have an opinion on this. Most systems code has to be "canonical". That means it can't be improved. Imagine the most difficult PR review you have ever had. Now give the reviewers OCD and an extra 30 IQ points. And every single code change has to live up to this standard. That's what it has to do with this. |
|
|
| |
| ▲ | kornelijus 3 hours ago | parent | prev [-] | | 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. |
|
|
| ▲ | ForHackernews 3 hours ago | parent | prev | next [-] |
| > It’s weird because those who actually care about optimized pg gains are most likely large corporate customers. Why make a product targeting them and license it in such a way they’ll never use it? Wait, sorry, you're asking why make something enterprise customers might pay for, and then not give it away to them for free? |
|
| ▲ | karlmush 3 hours ago | parent | prev [-] |
| AGPL seems like the right choice to me. I’m tired of companies like PlanetScale taking PostgreSQL, building a business on top of it, and then acting like PostgreSQL is theirs to control. |
| |
| ▲ | samlambert 3 hours ago | parent [-] | | we have not once claimed postgres is under our control. i don't think you understand how open source works but thats ok. |
|
