No, I had in mind different recent announcements when companies selected closed licenses that let you look at the code but not actually use it, then bragged about open sourcing their project.
Announcement title and actual license divergence has made reading these announcements a bit of a chore on HN since you're required now to read the full post. Good on these guys for not open washing their project.
And of course it doesn't help the tedium of reading HN that there's 5 very vocal commentators who want to the world to know that "OSI doesn't own the definition of open source", even though when asked will define open source as "can be commercially restricted".
We definitely really appreciate how open source leads to real innovation and actually useful code; no intention of openwashing here. Thank you for noticing that :-)
Thanks for flagging this. You’re right that the issue sat too long without a response, and that’s on us. We’ve now replied on GitHub and are actively looking into it. It appears the crash may be related to CPU feature mismatches (e.g. missing AVX support when using pgvector), especially in emulated environments like ARM Macs running x86 containers. We’ve asked for system details to help confirm. Happy to dig in and resolve it quickly from here.
From a security point of view, I am not comfortable giving a user unlimited access to the server. I don't know what solution pgEdge is implementing, but granting full access to the server when it should only operate on PostgreSQL is a security concern for me.
the Getting Started guide is definitely a different mindset than what we would recommend for Production Ready, particularly if there's specific security requirements in mind. With that being said, it should be more clear, so we've reported this to our documentation team to make sure it is!
I think it’s great they’re opening it up. I hope they have a plan to defend when the hyperscalers show up to pillage beyond providing cloud containers and VMs as a paid service.
Thanks for the feedback! We're pretty excited about it, too :-)
Citus focuses on scaling Postgres via sharding, typically with a single write node and many read replicas. It’s great for high-throughput, analytical workloads. pgEdge, by contrast, is built for geo-distributed, multi-master Postgres — all nodes are writable, with built-in conflict resolution. It prioritizes low latency, availability, and data locality over pure scale-out. So the goals are pretty different.
pgEdge came about from a pglogical foundation, actually! from one of our blogs:
> pgEdge emerged in late 2024 as a serverless distributed Postgres managed cloud service, delivering low latency and high availability in three minutes or less. The pgEdge Platform (for on-premises distributed PostgreSQL) as well as pgEdge Cloud (for deploying in the cloud) was largely inspired by the original capabilities of the pgLogical extension.
They really need to dial back on marketing bs.
async multimaster takes away consistency.
Piling on NewSQL DBS for slow synchronous writes to a quorum of nodes WTF?
async multi-master does trade off consistency for availability and latency. In PACELC terms, pgEdge leans into AP/EL, not CP. It’s built for low-latency local writes across regions, with built-in conflict resolution to manage eventual consistency. Definitely not trying to be a NewSQL quorum-write system. Just a different use case.
> pgEdge is a modern distributed database system built on standard PostgreSQL that’s designed for geo-distribution, high availability, and low latency — especially useful for "edge" deployments.
We're a little different in that we're not just 100% open-source, but also 100% compatible with community PostgreSQL. see https://pgscorecard.com for comparisons between pgEdge and YugabyteDB, CockroachDB on that front.
