HN Distilled

Essential insights from Hacker News discussions

OrioleDB Patent: now freely available to the Postgres community

Original Article

Hacker News Discussion

The discussion revolves around Supabase's OrioleDB project, its licensing, and its technical merits within the PostgreSQL ecosystem. Key themes include licensing concerns, patent grants and their implications, and the technical differentiators of OrioleDB.

Licensing and Patent Grant Concerns

A significant portion of the discussion centers on the initial licensing of OrioleDB, particularly the "poison pill" clause that terminated the license for any user who initiated litigation against Supabase, Inc., regardless of the lawsuit's nature. This clause was widely criticized for being overly broad and punitive, potentially discouraging adoption by larger organizations and violating the spirit of open source.

  • The "Poison Pill" Clause: The initial license was met with strong disapproval due to its broad termination clause.

    • "IF ANY LITIGATION IS INSTITUTED AGAINST SUPABASE, INC. BY A LICENSEE OF THIS SOFTWARE, THEN THE LICENSE GRANTED TO SAID LICENSEE SHALL TERMINATE AS OF THE DATE SUCH LITIGATION IS FILED."
    • "imho: the current wording might discourage state organisations, since even a trivial lawsuit (e.g. a minor tax delay) could terminate the licence - perhaps a narrower patent-focused clause would work better (or an OSI-approved licence?)."
    • "yellow_lead: A shield for Supabase, not for us"
    • "Reubend: So what? I don't see any conflict between what they said and what the license says. As they stated, it's being used as a shield. If you're suing them, you probably don't deserve a free license to their patented tech."
    • "samlambert: This is not an open source license and it's untrue to say it's an open source project when it's licensed this way."
    • "samlambert: "IF ANY LITIGATION IS INSTITUTED AGAINST SUPABASE, INC. BY A LICENSEE OF THIS SOFTWARE, THEN THE LICENSE GRANTED TO SAID LICENSEE SHALL TERMINATE AS OF THE DATE SUCH LITIGATION IS FILED." This is a poison pill. At best the licensing is naive and blocks even customers of Supabase from using OrioleDB, rather than at worst it's an attempt for Supabase to provide themselves unlimited indemnity through the guise of a community project."
    • "tomnipotent: The existing Postgres license already has an "as is" disclaimer, so adding this clause means you want to punitively punish companies that sue you for reasons outside of this software. The interpretation then is you want to punish users of your software that find themselves in a (potentially legitimate) situation to sue you over unrelated matters."
    • "victorbjorklund: Non go when it includes a poison pill."
    • "Fischgericht: Had a quick look at the patent, had a quick look at the code. To me it appears that 99,999% of all involved research has been taken from prior research from tons of scientists."

  • Comparison to Standard Open Source Licenses: Users pointed out that this clause deviated significantly from well-established open-source licenses like Apache 2.0 and contributed to the debate on whether OrioleDB was truly open source.

    • "916c0553e164269: Apache 2.0 has a better patent clause - against hostile IP claims, so tax dispute is not terminate the OrioleDB license:" followed by the Apache 2.0 patent clause.
    • "crote: It also seems a lot less strict on what is being terminated. On violation the Apache 2.0 license terminates the patent license. I might be mistaken, but that reads an awful lot like you're still allowed to use the software provided you do so in a way which doesn't violate the patent. On the other hand, the OrioleDB license seems to terminate the entire license - so the way I read this it would include parts of the software which aren't covered under the patent itself."
    • "cyphar: MPLv2 has a stronger version of this (I also personally prefer it in general to Apache-2.0 if you can't stomach GPLv3)."
    • "cyphar: A common issue with open source patent licenses is that they cannot grant blanket patent rights from contributors without some limitation around modifications, as it would allow someone to trivially render all of contributors' patents invalid (they just have to write a patch for the software that implements a patent you hold). GPLv3 has text about this in (s)11, MPLv2 has (s)2.3, and Apache-2.0 has s(3). GPLv2 doesn't have an explicit patent grant (and while some folks have argued that it has an implicit one that is just as good, I think the general consensus is that GPLv2 is not immune to patent trolls)."
    • "joshuaissac: I like how well-thought-out the licence revocation clause of the AOMedia patent licence is. It takes effect when a licensee sues over an implementation specifically over the relevant patent claims--so lawsuits unrelated to these patent claims are allowed (so if you infringe on other patents but also implement the licensed patent in the same implementation, the rights holder of the other patents can sue you over those claims without losing their licence)--and there is also a carve-out for counterclaims, and lawsuits to enforce this licence."
    • "Nightpool: Cypher in a sibling comment makes a good argument that this was the same logic (patent termination for legitimate, non-licensed patent claims) that got Facebook in trouble: https://news.ycombinator.com/item?id=45199687"
    • "tomnipotent: My take-away from the Facebook/React license issue was that the community agrees this violates the spirit of FOSS and invalidates claiming to be open source (at least OSI-approved), with many taking offense to the punitive nature of the clause."
    • "samlambert: lol no they both read as permissive on the surface. apache 2 doesn't include a termination clause that broadly protects an entity against any litigation. this is incredibly broad and not community safe."

  • Supabase's Response and Relicensing: Responding to the feedback, Supabase clarified their intentions and subsequently relicensed OrioleDB to Apache 2.0.

    • "kiwicopple: Iā€™ll revisit this with legal to try make it clearer. Our intentions here are clear - if people have examples that we can follow we will do what we can to make this irrevocable (even to the extent of donating the patent if/when the community are ready to bear the cost of the maintainance)"
    • "kiwicopple: sorry about the confusion - I wasn't as involved in this process as I should have been. My fault. This is now fixed: https://github.com/orioledb/orioledb/pull/558 The code is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer"
    • "kiwicopple: fixed - sorry about the confusion. https://github.com/orioledb/orioledb/pull/558 It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer"
    • "kiwicopple: sam, I think you know me well enough now to know that we're open source through and through. my mistake - I should have been more involved in this process with the team. It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed. I'll amend the blog to make that clearer. https://github.com/orioledb/orioledb/pull/558"
    • "maxloh: To reinforce the IP compatibility, Supabase is making available a non-exclusive license of U.S. Patent (ā€œDurable multiversion B+-treeā€) to all OrioleDB users, including proprietary forks, in accordance with the OrioleDB license. It seems that they have changed their mind to make it even more permissive. They just relicensed the OrioleDB project under Apache 2.0 an hour ago [0], which contains a patent clause."

OrioleDB's Technical Merits and Cloud-Native Aspects

The discussion also delved into the technical capabilities of OrioleDB, its "cloud-native" positioning, and its performance compared to standard PostgreSQL.

  • Storage Engine and Cloud Optimization: OrioleDB is presented as a new storage engine for PostgreSQL designed with cloud environments in mind, though the specifics of this "cloud-nativeness" were debated.

    • "8cvor6j844qw_d6: Is OrioleDB just PostgreSQL but with some underlying modifications for cloud environments?"
    • "LtdJorge: Itā€™s a different storage engine for Postgres"
    • "boxed: The "cloud environments" part sounds like marketing fluff. "The cloud" is just someone else's servers after all. There's nothing special about it."
    • "pbronez: In this case, it seems to refer to their support for S3-compatible object storage as for persistence."
    • "throwaway894345: What are the relevant differences? Iā€™m not as cynical as the parent commenter, but Iā€™m also unclear about what OrioleDB is doing that is meaningfully ā€œCloudNativeā€. From skimming the main page, it seems like itā€™s just doing storage differently, but so far Iā€™ve seen nothing to suggest that difference is ā€œleveraging cloud servicesā€ or anything else."
    • "IgorPartola: I am not familiar with this particular product but generally if you run on say AWS you either need to account for the greatly increased disk latency due to EBS being network storage or build provisions for local storage that is not necessarily unlimited, it is unclear what kind of disk controller it is attached to, etc. It could also mean optimizing for the AWS-specific CPU architecture. Or it could mean using S3 as storage which has yet different durability and consistency semantics compared to other storage systems. It might also mean optimizing for pricing of a given cloud provider in some way."
    • "grandfugue: If you take a look at how storage is billed in cloud, you'll see a huge difference. Networked storage, e.g., EBS, provides durability and survives VM restart. But it is billed on IOPS. 200K IOPS is a piece of cake for today's NVMe. But a 200K EBS easily costs you thousands per month. High-end NVMe devices, unfortunately, are all instance-level storage, which means they are gone if you shutdown your VM."

  • Performance Benchmarks and Technical Design: Users discussed OrioleDB's performance, its B-tree structure, and potential trade-offs.

    • "boxed: The graphs for OrioleDB looks very impressive. Can someone give a counter argument to switching to this?"
    • "wwizo: Oreole is not a plug-and-play yet. From their docs (https://www.orioledb.com/docs) > OrioleDB currently requires a set of patches to PostgreSQL to enhance the pluggable storage API and other PostgreSQL subsystems. All of these patches have been submitted to the PostgreSQL community and are under review."
    • "Sesse__: You get basically most of the advantages of a B-tree-oriented table, but also most of the disadvantages AFAIK. In particular, any index lookup/scan is going to take twice as long (index blocks don't point to the place on disk, they just contain the primary key and then you need to go lookup that in the actual table)."
    • "akorotkov: This is generally true, but there are some additional aspects. 1. With PostgreSQL heap, you need to access the heap page itself. And it's not for free. It goes all through the buffer manager and other related components. 2. In OrioleDB, we have a lightweight protocol to read from pages. In-memory pages are connected using direct links (https://www.orioledb.com/docs/architecture/overview#dual-pointers), and pages are read lock-less (https://www.orioledb.com/docs/architecture/overview#page-structure). Additionally, tree navigation for simple data types skips both copying and tuple deforming (https://www.orioledb.com/blog/orioledb-fastpath-search)."
    • "dkhenry: I am super bullish on OrioleDB. It really seems like the next logical progression for scaling Postgres for 99% of all databases out there. I have been following their development for a while and running benchmarks to see if their performance claims are legitimate, and so far it has been amazing https://airtable.com/app7jp5t0dEHyDpa8/shr00etqywoDW2N6N"
    • "btown: Based on the README [0] and discussion [1] it seems like it might especially shine on high-write-volume workflows, with the implementation of anti-bloat measures. Do you have a sense for whether it would shine even further where those rows have large text/JSONB fields that might be TOASTed? And more generally, curious if you have any sense for what might make up the "1%" of workflows this wouldn't be advisable for? Any downsides to be aware of?"

  • Transaction Isolation Levels: The absence of SERIALIZABLE isolation was noted as a current limitation.

    • "dangoodmanUT: OrioleDB tables don't support SERIALIZABLE isolation level. This is an unfortunate limitation to be aware of when evaluating https://www.orioledb.com/docs/usage/getting-started#current-limitations"
    • "akorotkov: We will eventually add the SERIALIZABLE isolation level to OrioleDB, but right now that's not our highest priority. Let me explain why. At first, SSI (serializable snapshot isolation) in PostgreSQL comes with significant shortcomings, including. 1) Overhead. SSI implies a heavyweight lock on any involved index page or heap tuple (even for reads). The overhead of SSI was initially measured at ~10%, but nowadays, scalability has gone much farther. These many HW-locks could slow down in multiple times a typical workload on a multicore machine. 2) SSI needs the user to be able to repeat any transaction due to serialization failure. Even a read-only transaction needs to be DEFERRABLE or might be aborted due to serialization failure (it might "saw impossible things" and needs a retry)."
    • "tux3: I had a case just recently where we needed to enforce a no-overlap constraint too complicated to express in an index (recurring time ranges). Any time you have to check constraints manually, you can't just do it before the write, or after the write, because two REPEATABLE READ write transactions will not see each other's INSERT. You need something like a lock, a two-phase commit, or SERIALIZABLE isolation for writes. Advisory locks have sharp edges, and 2PC is not so simple either, there is a lot that can go wrong."

Software Patents and Innovation

The discussion touched upon the broader topic of software patents, their impact on innovation, and contrasted different approaches, including those of China and the US.

  • Patenting Data Structures: The idea of patenting data structures was met with skepticism and criticism.

    • "0xb0565e486: I did not know you could patent data structures like that."
    • "fuzzy_biscuit: I strongly dislike the idea of patenting data structures."
    • "Fischgericht: Had a quick look at the patent, had a quick look at the code. To me it appears that 99,999% of all involved research has been taken from prior research from tons of scientists. You might have good intentions, but in my value system if you invite others to also enjoy what you have stolen, you still are just a thief. Polite reminder: Just because you managed to trick the US Patent Office into stamping your patent application does not mean you have invented something. It simply means you have managed to convince a bureaucrat to give you a stamp so you can claim ownership about other researchers' work. Want to be part of the good guys? Burn the patent, and apologize to the research community you tried to steal from."

  • US vs. Other Approaches to Patents: The US approach to software patents was contrasted with other international models, particularly China's perceived approach.

    • "gethly: Software patents is such an americanism. In this case, I prefer Chinese approach to ignoring patent law altogether."
    • "navigate8310: That simply kills innovation and dries up funding for research."
    • "henry700: It's what I think too, BUT curiously is not the case for China. Imagine if the DeepSeek breakthroughs were patented and closed instead of published in the open. And here we are, and they're not patented and not built on patented technology."
    • "Zetaphor: China is far ahead of the US in many sectors, notably electric cars and solar panels which are two industries whose progress heavily depend on research and innovation."
    • "throw0101d: China is far ahead of the US in many sectors, notably electric cars and solar panels which are two industries whose progress heavily depend on research and innovation. Ahead in production. Did China research/innovate/develop those industries, or were they 'just' fast followers? (Early in its history the US used the same 'tactics' relative to the UK and other European countries.)"
    • "tracker1: State-sponsored industrial espionage isn't the same as innovation."
    • "InTheArena: In general China has historically taken any sort of intellectual property rights and outright theft very differently then the rest of the developed world."

  • Open Source and Innovation: The overarching sentiment from several users was that open source drives innovation.

    • "iam_saurabh: Open-sourcing a patent in the database space is rare. Do you think this signals a shift where companies will realize that open ecosystems drive adoption faster than closed IP walls?"
    • "wslh: I think no-open-source is a no-go. In the "best" case it adds a lot of friction in a sales funnel for premium offerings. You can avoid open source in special cases, mostly without complementary offerings."
    • "gallypette: It is time to realize that open source drives innovation."