from the blog:
"The patent is intended as a shield, not a sword, to protect Open Source from hostile IP claims."
vs. the current license:
"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?).
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)
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.
Kudos to your legal team for working with you to provide a quick response. Licensing grants are momentous decisions it exceeds my expectations for you to act within the span of hours.
> "It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed."
It’s worth double-checking the relicensing angle.
Imho: you can only relicense your own code. Any 3rd party contribution stays under apache 2.0 unless the author explicitly agrees.
So a full switch to postgresql license is only possible if every contributor signs off. That usually means having a Contributor License Agreement (CLA) in place up front.
And ethically, contributors should already know their work might be relicensed under "postgresql terms" later - otherwise it's a surprise change for the community.
ps: if the plan is serious, do the legal homework early and gather consents now, so upstreaming to postgresql doesn’t fail later because a few open-source contributors (who aren’t supabase/orioledb employees) are unreachable.)
IANAL, but I don't think that is completely necessary for Apache 2.0. It isn't a copyleft license, so it's fine for derivative works (such as merging it into postgres) to use a different license. It would however create a bit of a hassle, since postgres would need to include the Apache license as well and make a note of the fact that the original code was also licensed under Apache 2.0.
> since postgres would need to include the Apache license
imho: given that postgres has many corporate forks and contributors from different companies, mixing apache 2.0 and postgresql licenses isn’t ideal - it complicates the legal picture and can even block upstream acceptance.
And if supabase's goal is really this [1], then it makes sense to think through the legal side now and start consulting with the upstream Postgres community early.
"We believe the right long-term home for OrioleDB is inside Postgres itself. Our north star is to upstream what’s necessary so that OrioleDB can eventually be part of the Postgres source tree, developed and maintained in the open alongside the rest of Postgres."
You could put it under a "PostgreSQL OR Apache-2.0 at your option" dual-license, so all contributors give you their code under both licenses, instead of needing to re-license later. The Rust project does this (MIT OR Apache-2.0) to get the patents clause from Apache while retaining compatibility with MIT and GPL.
If you do this, you need to have a very explicit policy for contributors to say they are contributing under both licenses, though this is something you need to have anyway if you are licensing under Apache 2.0 (a contributor could theoretically claim retroactively that their contributions were all MIT licensed and that they never gave you or any of your users a patent grant). (Most Rust projects do this.)
For other patent-shield licenses such a combination also removes most of the protections of the patent shield (a patent troll user can use the software under MIT and then sue for patent infrigement). However, the Apache 2.0 patent shield is comparatively weak (when compared to GPLv3 and MPLv2) because it only revokes the patent license rather than the entire license and so it actually acts like a permissive license even after you initiate patent litigation. This makes the above problem even worse -- if you don't actually have any patents in the software then a patent troll can contribute code under MIT then sue all of your users without losing access to the software even under just Apache 2.0 (I don't know if this has ever happened but it seems like a possibility).
IMHO, most people should really should just use MPLv2 if they want GPLv2 compatibility and patent grants. MPLv2 even includes a "you accept that your contributions to this project are under MPLv2" clause, avoiding the first problem entirely. It would be nice if there were an Apache 3.0 that had a stronger patent shield but still remained a permissive license (MPLv2 is a weak file-based copyleft), but I'm more of a copyleft guy so whatever.
> However, the Apache 2.0 patent shield is comparatively weak (when compared to GPLv3 and MPLv2) because it only revokes the patent license rather than the entire license and so it actually acts like a permissive license even after you initiate patent litigation.
Isn't the idea that you could then sue the suer for infringing your patent?
Sure, that is the point of the original point of the article after all. I was speaking about the problem in general (I suspect most Rust projects--if not most projects in general--with this setup do not have patents).
It also requires actively persuing a patent case which may result in the patent being rendered invalid, while a termination clause for the whole license just requires a far more clear-cut copyright infringement claim (possibly achievable purely through the DMCA system, out of court). But I'm not a lawyer, maybe counter-suits are more common in such situations and so either approach is just as good in practice.
Great, but Unlicense doesn't grant patent rights so you have the exact same problem as MIT (actually it's even worse because Unlicense explicitly states that it is only concerned with copyrights multiple times).
The whole patents kerfuffle with Facebook was about a larger issue with their patent grant. Critically the issue was that it practically stopped you from suing Facebook for any patent issues (not just those granted for React, which would be more like the standard reactive termination clause), including counter-suits. Here is the key text from their patent license:
The license granted hereunder will terminate, automatically and without notice,
for anyone that makes any claim (including by filing any lawsuit, assertion or
other action) alleging (a) direct, indirect, or contributory infringement or
inducement to infringe any patent: (i) by Facebook or any of its subsidiaries or
affiliates, whether or not such claim is related to the Software, (ii) by any
party if such claim arises in whole or in part from any software, product or
service of Facebook or any of its subsidiaries or affiliates, whether or not
such claim is related to the Software, or (iii) by any party relating to the
Software; or (b) that any right in any patent claim of Facebook is invalid or
unenforceable.
And so that was a fairly justified reaction IMHO. Funnily enough, it seems that the license written by Supabase has the same issue -- I suspect this might just be the "default approach" for patent lawyers.
However, MIT has _no_ patent protections and is strictly worse than almost any license with some patent protections for users included. The modern landscape of software patent trolls is far less insane than it was in the 90s but I would really think twice about using something that is likely patented under a license other than Apache-2.0, MPLv2, or GPLv3.
> 1.3. Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee).
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.
For example, if Supabase failed to pay a vendor that happened to use OrioleDB they wouldn't be able to sue you for damages without compromising their stack. That's uncool.
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.
Granted Facebook was in a position to see litigation over a lot more reasons.
That's just not true. Your license[0] adds a clause to the Postgresql license[1]. This makes it a different license, which by extension also means it isn't OSI approved.
It's the same with the BSD licenses[2]: the 4-clause one is OSI-approved, whereas the 3-clause one is not. Turns out that one additional "all advertising must display the following acknowledgement" clause was rather important - and so is your lawsuit clause.
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
From the phrasing it already seemed your heart was in the right place, but I understand that it can get tricky once people get involved who aren't as familiar with the details of open source licensing.
Getting legal to sign off on a different license this quickly is impressive!
(er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)
Anyway, I'm not sure this is true. Having a separate software license + secondary patent grant license is very very common in open source projects where patent trolls are common. See e.g. https://aomedia.org/about/legal/
I would just put them in separate files and then you're good to go.
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.
But I am not sure if the first exemption is necessarily a good thing. The Apache License, Version 2.0 is broader in what may be grounds for patent licence termination. So it is a better deterrent against patent trolls (even if that means some legitimate patent claims are also discouraged).
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
I re-read the text again and it's even worse than the Facebook one -- the entire license terminates in reaction to any litigation, not just patent litigation. Hypothetically, a former employee suing Supabase for violation of workers' rights would not be allowed to use the software anymore.
But they have switched to Apache 2.0 now, so crisis averted.
> (er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)
Whoops, I did indeed type that a bit too quickly.
> Having a separate software license + secondary patent grant license is very very common
Perhaps, but those are separate. In this instance it was one and the same license, with any violation of the patent part terminating the whole license - including the non-patented software parts.
Additionally, the AOMedia patent license seems to be a bit different: the OrioleDB one said it would terminate when you sued Supabase (and to make it worse: sue them for any reason), but the AOMedia one says it'll terminate if you sue anyone over the licensed patents.
In other words: the OrioleDB one protected only Supabase, the AOMedia one protects the entire community. When it comes to being compatible with open source licenses, details like that become crucial.
The PostgreSQL license does not have a termination clause, you added that. I see that you are trying to use the PostgreSQL license as the basis and simply add the patent clause onto it, but it fundamentally changes the license.
I hope you can look at the Apache 2 patent grant as a better clause- or even adopt something like Google's Additional IP License found here- https://www.webmproject.org/license/additional/, which doesn't modify the open source license but instead adds an additional grant as a separate license.
Microsoft used it a ton, until they eventually just made everything open-source fall under the MIT license.
Some people will still be angry about it (I got a downvote for just mentioning it elsewhere on this thread) but as the person who built your software, you have every right to license your software as you deem necessary. There is a cost to what you've built and you have no true obligation to give everything for free.
On that note, as far as I can remember the MS-PL is OSI approved already.
Apache 2.0 has a better patent clause - against hostile IP claims, so tax dispute is not terminate the OrioleDB license:
"If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."
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.
Does the current license even allow for friendly forks, or redistribution?
It starts off nice with the usual:
> PERMISSION TO USE, COPY, MODIFY, AND DISTRIBUTE THIS SOFTWARE AND ITS DOCUMENTATION FOR ANY PURPOSE, WITHOUT FEE, AND WITHOUT A WRITTEN AGREEMENT IS HEREBY GRANTED
.. but then there's the:
> HEREBY GRANTS A (..) LICENSE TO UNITED STATES PATENT NO. 10,325,030 TO MAKE, HAVE MADE, USE, HAVE USED, OFFER TO SELL, OFFERED TO SELL, SELL, SOLD, IMPORT INTO THE UNITED STATES, IMPORTED INTO THE UNITED STATES, AND OTHERWISE TRANSFER THIS SOFTWARE
.. which to me seems to be missing some kind of "modify" clause? Sure, it seems like you're allowing me to distribute it as-is the way a store like Amazon distributes boxes, but what happens when I start modifying the code and distributing those modifications? Is it still "this software", or has it become a derivative? Is the license I get to that patent even sublicensable? What happens to users of a fork when the forkee sues Supabase: do they also by extension lose their patent license?
The GPLv2, for example, has a clause stating that "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor" which makes it very clear what happens. If you're adding a poison pill to open-source code, you really shouldn't be this sloppy: it should be painfully obvious to every reader what the implications are, or nobody will ever risk using it.
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). All of them still allow you to make modifications but they do not guarantee that some other patents will not be infringed by your modifications and open you up to patent lawsuits (even from the same entity).
Assuming a lawyer wrote this, this is probably part of the reason for it. But it does feel a little sloppy, a separate patent license with clear terms would probably be more preferable.
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.
The difference is that the license is terminated by ANY litigation against Supabase - e.g. if you sue them for breach of contract completely unrelated to the software.
Use as a shield would mean limiting it to patent litigation against a user of the software.
It also only covers litigation against Supabase - it does not provide a shield against litigation against OrioleDB users.
You need to read the text more carefully -- the license terminates for any litigation against Supabase at all. Hypothetically, a former employee of Supabase suing them for some employee rights violation would no longer be allowed to use the software, which is not the case for any other OSI-approved license with patent shields.
The MS-PL has the fairly standard reactive patent shield that only activates for patent-related litigation for the specific software under the license and is kind of similar to the language in Apache 2.0, MPLv2, and GPLv3.
But they have now switched to Apache 2.0, so crisis averted.
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.
> 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.
How'd you arrive at this conclusion? The stuff in the body of the patent can be expected to be 99.99% of widely known stuff, always.
What counts is that something new is disclosed, and that is what the claims cover.
A description of a patent must be enabling: it must tell someone ordinarily skilled in the art enough to reproduce the claimed invention. Gesticulating at "you could find a bunch of the simpler steps in earlier research papers" is not good enough.
How far attorneys go to make sure a patent description is wildly varying (I remember some of my earlier ones take some time to describe what a CPU and program are...) but it's best to error on the side of caution and describe well known techniques. Otherwise, you might spend time arguing in future litigation about whether the average software engineer in 2015 knew how to do a particular thing.
True. For some of my patents, the write ups make clear that the attorneys didn’t really understand how things worked. At some point, reviewing these things, you have to say, “Yea, okay, close enough,” and sign off on it.
You're being entirely unfair to Supabase here. Research is important, but there is a reason why the USPTO has developed substantial case law around Reduction to Practice, everything is built on prior work, so to say there is nothing novel about actually building displayed working system from parts is factually inaccurate.
Yeah, huge props here. There's a contingent on HN that seems to assume that almost any action by a company is done in bad faith. I dislike all of the shady stuff that happens, but that's why we should celebrate when companies are doing awesome things.
This is all positive. Super appreciate what you folks have done. It's clearly hard, well intentioned, and thoughtfully executed.
People might say that the company is doing it for good will, but that is the point, it is better to get the good will of the users by actually helping them instead of being like thousands of other companies which don't even do that.
It is a nuanced topic but I feel like we should encourage companies which do good period. (like silksong / team cherry in gaming) etc.
why? the usual OSI licenses all work through copyright, and through conditional granting of rights (hence the name license)
for a parent granting irrevocable royalty-free usage rights to anyone is equivalent to putting it into the public domain, no?
both copyright and a patent grants exclusive rights to the rightsholder (right to perform, modify, or in case of patents to use the invention in the way covered by one of the claims), and the rightsholder is free to include more persons in the group of authorized users (ie. extend the rights to others, and can do so conditionally - hence the Apache2 patent grant)
can you please explain where my understanding is incorrect or missing something? thanks!
For example there a lot of ways to use the so-called priority of the US patent to file other patents, including elsewhere in the world.
US Americans sadly often forget that the majority of the planet is not the USA. Here in Thailand, US and EU pharma companies have managed to get patents on 15 year old basic stuff like anti-histaminic meds. "Oh, but the system of limited monopoly in the US worked for us?". Yeah. But in Europe, the cost per pill is somewhere around $0.08. In Europe it's about $0.02. In Thailand it's $0.80 because Zyrtec managed to file a patent here re-using the priority of the US patent. And wage-adjusted in Thailand the cost per pill is about $15 per pill. You better don't have an allergy over here. So: Patents can have long-term consequences.
Back to IT: Have a look at the whole patent troll industry. The biggest chunk of junk patents that they bought are coming from "we will not do any harm" owners/filers. A lot can happen in 20 years.
Ah, I completely support your righteous anger against the tragicomedy of US "IP colonisation", though note that it has not much to do with my comment about the possibility of an open source patent.
The fact that most of the world was just laying down belly up to accept the negative consequences of the ridiculous cottage industry of churning out patents "for later" is truly enraging if someone gets to see how little value it produces. (It's very convenient for large conglomerates, VC fueled startups, and ... that's it.)
When it comes to specifics, ie. with pharma, it's hard to really disentangle the mess from other ugly facts, like the post-WWII global economy which and the very misregulated US healthcare industry (R&D including).
The US is subsidizing R&D for the world, because the other rich countries have sane "collective bargaining", but this leaves the small not so rich markets out in the fucking cold, because they have a weak bargaining position (market access doesn't worth that much to pharma companies) and also usually no internal R&D (so no local companies filing for these trivial parents). But because of all this in effect the world is buying R&D at the worst price!
(Though of course the picture is more complicated than this, but R&D is definitely waaay too inefficient in the US, but also all over the world too.)
The intention of OrioleDB is not to compete with Postgres, but to make Postgres better. We believe the right long-term home for OrioleDB is inside Postgres itself. Our north star is to upstream what’s necessary so that OrioleDB can eventually be part of the Postgres source tree, developed and maintained in the open alongside the rest of Postgres.
This comment makes no sense. They're actively open sourcing the patent and trying to get it upstream into Postgres. They purchased another company to get this patent, and they're spending a lot of money on lawyers to figure out how to release it to the community.
Call out shady shit when companies do shady things, but the sentiment behind this comment seems to be looking for reasons to bee outraged instead of at what's actually being done.
If companies get evicerated every time they try to engage with the community they'll stop engaging. We should be celebrating when they do something positive, even if there are a few critiques (e.g. the license change call out is a good one). Instead, half the comments seem like they're quick reactions meant to stoke outage.
Please have some perspective - this action is a win for the community.
I am "owner" of a bunch of patents, too, and some have actually been proven their test of time by after years having been re-invented (better: "parallel-invented later in time") elsewhere in the open source world.
But in my value system one does not do press releases saying "HELLO! We have decided not to do something evil!".
They could have done the very same thing done quietly to make clear there is no hidden agenda.
"Look, we hold this trivial patent on the open source ecosystem. No no no, all will be fine. No, no, we will not pick up the phone should Broadcom call us one day."
> 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.
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?
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.
According to the docs, it “uses Postgres Table Access Method (TAM) to provide a pluggable storage engine for PostgreSQL. […] Pluggable Storage gives developers the ability to use different storage engines for different tables within the same database. Developers will be able to choose a storage method that is optimized for their specific needs: some tables could be configured for high transactional loads, others for analytics workloads, and still others for archiving.”
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
The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then it should be simpler for anyone to write their own Storage extensions.
I think (correctly) it will take a lot longer to upstream the extension - the PG community should take a “default no” attitude with big changes like this. Over time we will prove its worthiness (hopefully beyond just supabase - it would be good to collaborate with other Postgres providers)
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?
I haven't explicitly tested how it handles TOASTed column's, but since there is an upcoming RC I will try it out next time. I don't generally like using JSONB/text columns for very large rows as they have other performance problems on the DB like causing lots of WAL write overhead.
In term of other workloads it might not be great for, all my testing has shown a great improvement in every workload I have thrown at it.
OrioleDB looks interesting but the with the storage changes, the issue will be the compatability with other extensions. pg_search (paradedb), timescale come to mind.
We have seen this issue with YugabyteDB, and their integration off RocksDB as the storage engine for postgresql.
As far as I know, you can run heap and orioledb tables side by side in the same system, so I don’t see a problem using heap-based extensions like timescale together with orioledb.
( of course timescale doesn’t support OrioleDB storage yet, but they can run in parallel. )
and many extensions (e.g. postgis) already work fine with OrioleDB storage.
IP owners often play the game of “patent what you can, threaten with the rest.” So you might not be able to strictly patent the way data is laid out, but specific, novel algorithms that update or manipulate that layout and improve what was possible before? Those can be understood as key steps of an “innovative process”—and courts have been willing to uphold process claims, especially when tied to what they understand are genuine technical improvements. Fighting even a marginal patent usually means a long, expensive slog with plenty of downside risk.
IANAL nor a patent judge, but this is my understanding after watching the space for some years.
But at the same time, globalization means legal mandates are increasingly extra-territorial in scope and impact. U.S. patent law affects anyone whose products touch the American market.
Similarly, CCPA/CPRA and GDPR reach far beyond their nominal geographic borders.
That's juridiction dependent. Europe didn't allow such a thing last time I checked. But lobbying to do so as been recurrent on this topic, just like putting governmental backdoor everywhere. They will try until it passes. There should be legal penality for such a stubborn will to destroy civil liberty. At least in this case they can't play the card "think of the children, nazi pedophiles use this".
In general China has historically taken any sort of intellectual property rights and outright theft very differently then the rest of the developed world.
That's just the path for all who do this stuff. America seems culturally to like IP (everyone saying that copyright law is paramount and LLMs should be stopped, etc.) but that's just recent history.
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.
> 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.)
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.
Probably because DeepSeek creators were afraid government would just come and take it from them. The only solution was to open source it which is kind of a big middle finger to the Chinese government.
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).
In contrast, typically it's not hard to resolve the concurrency problems of writing transactions using explicit row-level and advisory locks, while REPEATABLE READ is enough for reporting. Frankly speaking, during my whole career, I didn't see a single case where SERIALIZABLE isolation level was justified.
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.
In the case of SERIALIZABLE you do need to retry in case of conflict, but usually the serialization anomalies can be limited to a reasonably fine level. And an explicit retry feels safer than risking a livelock situation when there is contention.
This seems like a fascinating problem domain! I'm incredibly curious what product you're working on - if you're taking this much attention to detail on recurring events, it seems like it's a step beyond most scheduling systems I've seen.
(I've had to implement the naive approach here, which nested-loops over dates and rules and finds ones that might conflict. Definitely not meant to scale, and would be a nightmare if not at a date-level granularity!)
No pressure to share, but would love to learn more!
It's a scheduling system in the medical field where recurring events can happen in a particular room, this might be every N days at a particular time, or every three weeks on Tuesday and Friday between some start date and some end date.
I'm not entirely familiar with the literature, so we did some simplifications to keep it manageable, and it's very possible there might be a better approach!
We model the events generated by our recurring rules as intervals [SA+n*A, SA+n*A+DA), where A is a constant integer number of days (e.g. A=3*7 for an event on Tuesday every 3 weeks), SA is the start date, and DA is the duration of an event (... which can be >24h to make things more interesting). It might continue recurring forever, or it might stop by some end date.
Now if you have two of these recurring events with periods A and B, you can think of each of them as a periodic function, and the combination of them will have a period equal to LCM(A, B). So we could check everything modulo LCM(A, B) once, and that would hold infinitely far forward.
But actually, we can do even better by taking the difference Δ=SA-SB mod GCD(A, B). You can sort of think of it as the closest approach between these two recurring events. If that's less than DA or more than the GCD-DB, these events are eventually going to overlap. There's some extra details to check whether overlap happens before either end date (if any), but that's the idea in a nutshell.
---
Where it gets really interesting is when you introduce timezones and daylight savings time (DST). Now a day is not always 24h, so there isn't a nice [SA+n*A, SA+n*A+DA) at regular intervals, and we can't naively work modulo the LCM or GCD anymore.
But we can notice that the days of the year on which a DST transition falls generally follow simple rules, and would repeat every 28 years (actually every 400 years due to leap years). In practice for a given timezone, for example CEST, there are only 14 unique days of the year on which the DST transitions can fall, and it repeats after a full period.
So if we want to check for overlap, we can treat those DST transition days as special cases, and all the time intervals in between DST transition days look locally "UTC-like" (time doesn't jump forward or backwards, if we ignore leap seconds), so the previous formula continues to work on all of these.
But at some point things become a little messy, so we did some simplifications =)
My napkin math suggests the size of the supercycle when you take two recurring events A and B with periods < 365 days and the 400 year cycle for DST transition can be about a hundred thousand years in the worst case.
But considering that timezones and daylight savings time are fundamentally political decisions, and that the IANA tzdata file is updated regularly, there is not much sense in applying the current rules thousands of years into the future! So we check at most 400 years ahead, and we consider that when timezones are involved, the overlap check is best effort and we prepare for the fact that it could miss a DST transition – no matter what math we do, a country could change the rules at any time, and a day that used to be 24h could now be 25, 22:30, or even skipped entirely, invalidating all past assumptions.
Thank you so much for sharing this! That sounds like an equally fun and headache-inducing problem indeed!
The idea that someone could book a room for 400 years of consistency guarantees is somewhat hilarious, yet absolutely the kind of thing that would check a box in a regulated environment like healthcare!
It does speak to a larger issue I see quite often, which is that capturing structured intent as of the time an event is created, with the context that led to that decision, is incredibly hard to model. Because no matter what, something about the system will change, like daylight savings time or assumptions around resource/room availability, in an unpredictable way such that the data that had been used to drive a confident evaluation of lack-of-conflict at insertion time, is now insufficient to automatically resolve conflicts.
There's no single way to solve this problem - in a way, "reinterpreting intent" is why programming is often equal parts archaeology and anthropology. Certainly gives us very interesting problems to solve!
To circle it back to the original conversation: the better our databases are at handling large volumes of written data, the more context we can capture around insertion-time intent in an easy-to-query way, and the better we'll be at adapting to unforeseen circumstances!
I use SERIALIZABLE on a database for which I have very low writer concurrency (I can count the total writer connections on 1-2 hands) and where I really, really, really don’t want to deal with the fallout if a transaction commits and results in an impossible state.
I use MySQL, not Postgres, for this application (for better or for worse), and I can absolutely generate a bad state if I drop MySQL to a level below SERIALIZABLE — I’ve tried it. (Yes, I could probably avoid this with SELECT FOR UPDATE, but I don’t trust MySQL enough and I get adequate performance with SERIALIZABLE.)
To make SERIALIZABLE work well, I wrap all the transactions in retry loops, and I deal with MySQL’s obnoxious reporting of which errors are worthy of retries.
(Aside from bad committed states, I’ve also seen MySQL return results from a single straightforward query that cannot correspond to any state of the table. It was something like selecting MIN, MAX and COUNT(*) from a table and getting min and max differing and count = 1. It’s been a while — I could be remembering wrong.)
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.
"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, at worst it's an attempt for Supabase to provide themselves unlimited indemnity through the guise of a community project. It means the moment you sue Supabase for anything. Contract dispute, IP, employment, unrelated tort you lose the license. They could lose your data and if you try do anything about it they can immediately counter sue for a license violation. Using the brand of the postgres license to slip this in is pretty wild.
OrioleDB looks like a promising project and undoubtedly an great contribution from Supabase but it's not open source or really usable by anyone with this license.
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.
I recall Facebook had a similar rider on the React license for many years until eventually removing it. It’s visually similar to the Apache2 patent clause but not scoped to just the licensed software use
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.
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.
I think that "under review" claim is doing some very heavy lifting, especially when it relates to their changes to index tuple lifecycle management. The patches that have been submitted are unlikely to get committed in full anytime soon, even after substantial changes to the patches' designs.
PostgreSQL just has not been designed for what OrioleDB is doing, and forcing OrioleDB's designs into PostgreSQL upstream would a lot of (very) sharp edges that the community can't properly test without at least a baseline implementation - which critically hasn't been submitted to upstream. Examples of these sharp edges are varsized TIDs, MVCC-owning indexes, and table AM signalled index inserts.
There are certainly ideas in OrioleDB's designs that PostgreSQL can benefit from (retail index tuple deletion! self-clustering tables!), but these will need careful consideration in how this can be brought into the project without duplicating implementations at nearly every level. A wholesale graft of a downstream fork and then hoping it'll work out well enough is just not how the PostgreSQL project works.
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).
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.
According to all of the above, I believe OrioleDB still wins in the case of secondary key lookup. I think this is indirectly confirmed by the results of the TPC-C benchmark, which contains quite a lot of log of secondary key lookups. However, this subject is worth dedicated benchmarking in the future.
It would be interesting to see how OrioleDB does with more OLAP-like loads. From when I spent a lot of time benchmarking this, the indirect index design was _the_ main reason why MySQL+InnoDB was losing significantly to Postgres on TPC-H (well, DBT-3).[1] There was a lot of working around it with covering indexes etc..
Of course, the flip side of the coin is that if you do an UPDATE of a row in the presence of a secondary index, and the UPDATE doesn't touch the key, then you don't need to update the index(es) at all. So it really depends on how much you update rows versus how often you index-scan them IME.
[1] TPC-H doesn't have difficult enough queries to really stress the planner, so it mattered comparatively less there than in other OLAP work.
This is why Postgres b-tree indexes offer CREATE INDEX (indexCol1, indexCol2, ...) INCLUDE (includeCol1, includeCol2, ...). With INCLUDE, the index will directly store the listed additional columns, so if your query does `SELECT includeCol1 WHERE indexCol1 = X AND indexCol2 > Y`, you avoid needing to look up the entire row in the heap, because includeCol1 is stored in the index already. This is called a "covering index" because the index itself covers all the data necessary to answer the query, and you get an "index only scan" in your query plan.
The downside to creating covering indexes is that it's more work for Postgres to go update all the INCLUDE values in all your covering indexes at write time, so you are trading write speed for increased read speed.
I think it's quite typical to see this in SQL databases. SQLite behaves the same way for indexes; the exception is that if you create a WITHOUT ROWID table, then the table itself is sorted by primary key instead of by ROWID, so you get at most 1 index that maps directly to the row value. (sqlite docs: https://sqlite.org/withoutrowid.html)
That link directly contradicts what you are saying.
> This means that in an ordinary index scan, each row retrieval requires fetching data from both the index and the heap.
Note that it says _index and the heap_. Not _index and the primary index and the heap_. (For a B-tree-organized table, the leaf heap nodes are essentially the bottom of the primary index, so it means that to find anything, you need to follow the primary index from the top, which may or may not entail extra disk accesses. For a normal Postgres heap, this does not happen, you can just go directly to the right block.)
Index-only scans (and by extension, INCLUDE) are to avoid reaching into the heap at all.
> The downside to creating covering indexes is that it's more work for Postgres to go update all the INCLUDE values in all your covering indexes at write time, so you are trading write speed for increased read speed.
For updates, even those that don't touch INCLUDE values, Postgres generally needs to go update the index anyway (this the main weakness of such a scheme). HOT is an exception, where you can avoid that update if there's room in the same heap block, and the index scans will follow the marker(s) you left to “here's the new row!” instead of fetching it directly.
Ah gotcha. My understanding of the heap reference was that heap lookups involve traversing a heap-like tree data structure, not a direct link to a specific leaf page.
Based on the limited description of OrioleDB I understand it works like SQLite WITHOUT ROWID, actually storing the row tuple in the primary key b-tree, but I didn’t go read the code
It's confusing nomenclature, but Postgres' “heap” is not a heap (B-tree) data structure. It is just a bunch of blocks all on the same level, similar to how the “heap” in an operating system (as opposed to the stack) is.
Notably, you can have a Postgres table without a primary key at all, not even an implicit one.
> Based on the limited description of OrioleDB I understand it works like SQLite WITHOUT ROWID, actually storing the row tuple in the primary key b-tree, but I didn’t go read the code
Legal shield? So once again people have to do manual legal work for something that can be taken for granted in any (L)GPL* software.
We should start counting the times a permissive-licensed software needs this kind of protection, and then wonder what is the difference between all this effort and just going GPL.
You don't need to hang onto hopes and public shaming until someone else does the hard part.
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.
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.
I agree that all of those things could be true, but I haven't read anything that indicates any special dependency on or knowledge of proprietary cloud systems. As far as I can tell, it's just going to use whatever disk/CPU you give it?
Wait when you need to manage a bunch of servers yourself. Unfortunately, the solutions available are complex, and not something where you can simply points something to a server, or VPS, and have a quick total controlled kernel level solution. K8, sure, but even that is not on the same level. And when you then need to manage DB's, your often placing those outside K8. Most scalable solutions like CRDB (10m pay, required yearly "free" license approval), Yugabyte(half broken), TiDB ... have their own issues and again, do not tie into a complete managed cloud experience.
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.
from the blog: "The patent is intended as a shield, not a sword, to protect Open Source from hostile IP claims."
vs. the current license:
( https://github.com/orioledb/orioledb/blob/main/LICENSE )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?).
(Supabase ceo)
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)
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.
Kudos to your legal team for working with you to provide a quick response. Licensing grants are momentous decisions it exceeds my expectations for you to act within the span of hours.
This change looks much better, thanks!
> "It is now Apache 2.0 which grants patent rights and can be re-licensed to PostgreSQL when the code is upstreamed."
It’s worth double-checking the relicensing angle. Imho: you can only relicense your own code. Any 3rd party contribution stays under apache 2.0 unless the author explicitly agrees.
So a full switch to postgresql license is only possible if every contributor signs off. That usually means having a Contributor License Agreement (CLA) in place up front.
And ethically, contributors should already know their work might be relicensed under "postgresql terms" later - otherwise it's a surprise change for the community.
ps: if the plan is serious, do the legal homework early and gather consents now, so upstreaming to postgresql doesn’t fail later because a few open-source contributors (who aren’t supabase/orioledb employees) are unreachable.)
IANAL, but I don't think that is completely necessary for Apache 2.0. It isn't a copyleft license, so it's fine for derivative works (such as merging it into postgres) to use a different license. It would however create a bit of a hassle, since postgres would need to include the Apache license as well and make a note of the fact that the original code was also licensed under Apache 2.0.
> since postgres would need to include the Apache license
imho: given that postgres has many corporate forks and contributors from different companies, mixing apache 2.0 and postgresql licenses isn’t ideal - it complicates the legal picture and can even block upstream acceptance.
And if supabase's goal is really this [1], then it makes sense to think through the legal side now and start consulting with the upstream Postgres community early.
[1] https://supabase.com/blog/orioledb-patent-free#aligned-with-...
"We believe the right long-term home for OrioleDB is inside Postgres itself. Our north star is to upstream what’s necessary so that OrioleDB can eventually be part of the Postgres source tree, developed and maintained in the open alongside the rest of Postgres."
Clarification:
As I see it, postgresql already includes a small amount of Apache 2.0 licensed code.
So it’s not as big an issue as I originally thought.
https://github.com/search?q=repo%3Apostgres%2Fpostgres%20apa...
example:
https://github.com/postgres/postgres/blob/88824e68611a88a4ef...
Great, thanks for this - we’ll make sure we have something in place
You could put it under a "PostgreSQL OR Apache-2.0 at your option" dual-license, so all contributors give you their code under both licenses, instead of needing to re-license later. The Rust project does this (MIT OR Apache-2.0) to get the patents clause from Apache while retaining compatibility with MIT and GPL.
If you do this, you need to have a very explicit policy for contributors to say they are contributing under both licenses, though this is something you need to have anyway if you are licensing under Apache 2.0 (a contributor could theoretically claim retroactively that their contributions were all MIT licensed and that they never gave you or any of your users a patent grant). (Most Rust projects do this.)
For other patent-shield licenses such a combination also removes most of the protections of the patent shield (a patent troll user can use the software under MIT and then sue for patent infrigement). However, the Apache 2.0 patent shield is comparatively weak (when compared to GPLv3 and MPLv2) because it only revokes the patent license rather than the entire license and so it actually acts like a permissive license even after you initiate patent litigation. This makes the above problem even worse -- if you don't actually have any patents in the software then a patent troll can contribute code under MIT then sue all of your users without losing access to the software even under just Apache 2.0 (I don't know if this has ever happened but it seems like a possibility).
IMHO, most people should really should just use MPLv2 if they want GPLv2 compatibility and patent grants. MPLv2 even includes a "you accept that your contributions to this project are under MPLv2" clause, avoiding the first problem entirely. It would be nice if there were an Apache 3.0 that had a stronger patent shield but still remained a permissive license (MPLv2 is a weak file-based copyleft), but I'm more of a copyleft guy so whatever.
> However, the Apache 2.0 patent shield is comparatively weak (when compared to GPLv3 and MPLv2) because it only revokes the patent license rather than the entire license and so it actually acts like a permissive license even after you initiate patent litigation.
Isn't the idea that you could then sue the suer for infringing your patent?
Sure, if you have a patent. If you don't and the patent shield is intended more as pre-emptive protection then MPLv2 or GPLv3 are better.
In this case, they do have a patent.
Sure, that is the point of the original point of the article after all. I was speaking about the problem in general (I suspect most Rust projects--if not most projects in general--with this setup do not have patents).
It also requires actively persuing a patent case which may result in the patent being rendered invalid, while a termination clause for the whole license just requires a far more clear-cut copyright infringement claim (possibly achievable purely through the DMCA system, out of court). But I'm not a lawyer, maybe counter-suits are more common in such situations and so either approach is just as good in practice.
I always use the easy license for this stuff: Unlicense lol
Great, but Unlicense doesn't grant patent rights so you have the exact same problem as MIT (actually it's even worse because Unlicense explicitly states that it is only concerned with copyrights multiple times).
Thanks for the quick fix.
Facebook famously dropped Patents from their BSD + Patents for React and a bunch of other projects, and went MIT unencumbered.
https://engineering.fb.com/2017/09/22/web/relicensing-react-...
The whole patents kerfuffle with Facebook was about a larger issue with their patent grant. Critically the issue was that it practically stopped you from suing Facebook for any patent issues (not just those granted for React, which would be more like the standard reactive termination clause), including counter-suits. Here is the key text from their patent license:
And so that was a fairly justified reaction IMHO. Funnily enough, it seems that the license written by Supabase has the same issue -- I suspect this might just be the "default approach" for patent lawyers.However, MIT has _no_ patent protections and is strictly worse than almost any license with some patent protections for users included. The modern landscape of software patent trolls is far less insane than it was in the 90s but I would really think twice about using something that is likely patented under a license other than Apache-2.0, MPLv2, or GPLv3.
Google has a strong patent shield situation with AV1. Despite burning interest from patent trolls, no one is going after AOMedia members directly.
Agree with this—the A/V media system has some of the most active patent trolls around. https://aomedia.org/license/patent-license/
The relevant patent license is the following:
> 1.3. Defensive Termination. If any Licensee, its Affiliates, or its agents initiates patent litigation or files, maintains, or voluntarily participates in a lawsuit against another entity or any person asserting that any Implementation infringes Necessary Claims, any patent licenses granted under this License directly to the Licensee are immediately terminated as of the date of the initiation of action unless 1) that suit was in response to a corresponding suit regarding an Implementation first brought against an initiating entity, or 2) that suit was brought to enforce the terms of this License (including intervention in a third-party action by a Licensee).
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.
For example, if Supabase failed to pay a vendor that happened to use OrioleDB they wouldn't be able to sue you for damages without compromising their stack. That's uncool.
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.
Granted Facebook was in a position to see litigation over a lot more reasons.
Appreciate the intent!
For practical adoption, especially in larger orgs, OSI-approved licences are much easier to get through legal review than custom ones.
The current license is PostgreSQL (which is OSI approved)
We could also change to MIT/Apache but we feel PostgreSQL is more appropriate given our intentions to upstream the code
> The current license is PostgreSQL
That's just not true. Your license[0] adds a clause to the Postgresql license[1]. This makes it a different license, which by extension also means it isn't OSI approved.
It's the same with the BSD licenses[2]: the 4-clause one is OSI-approved, whereas the 3-clause one is not. Turns out that one additional "all advertising must display the following acknowledgement" clause was rather important - and so is your lawsuit clause.
[0]: https://github.com/orioledb/orioledb?tab=License-1-ov-file
[1]: https://github.com/postgres/postgres?tab=License-1-ov-file
[2]: https://en.wikipedia.org/wiki/BSD_licenses#4-clause_license_...
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
Thanks for the fix!
From the phrasing it already seemed your heart was in the right place, but I understand that it can get tricky once people get involved who aren't as familiar with the details of open source licensing.
Getting legal to sign off on a different license this quickly is impressive!
(er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)
Anyway, I'm not sure this is true. Having a separate software license + secondary patent grant license is very very common in open source projects where patent trolls are common. See e.g. https://aomedia.org/about/legal/
I would just put them in separate files and then you're good to go.
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.
But I am not sure if the first exemption is necessarily a good thing. The Apache License, Version 2.0 is broader in what may be grounds for patent licence termination. So it is a better deterrent against patent trolls (even if that means some legitimate patent claims are also discouraged).
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
I re-read the text again and it's even worse than the Facebook one -- the entire license terminates in reaction to any litigation, not just patent litigation. Hypothetically, a former employee suing Supabase for violation of workers' rights would not be allowed to use the software anymore.
But they have switched to Apache 2.0 now, so crisis averted.
> (er, surely it's the other way around? the 3-clause one is OSI approved and the 4-clause one is not)
Whoops, I did indeed type that a bit too quickly.
> Having a separate software license + secondary patent grant license is very very common
Perhaps, but those are separate. In this instance it was one and the same license, with any violation of the patent part terminating the whole license - including the non-patented software parts.
Additionally, the AOMedia patent license seems to be a bit different: the OrioleDB one said it would terminate when you sued Supabase (and to make it worse: sue them for any reason), but the AOMedia one says it'll terminate if you sue anyone over the licensed patents.
In other words: the OrioleDB one protected only Supabase, the AOMedia one protects the entire community. When it comes to being compatible with open source licenses, details like that become crucial.
The PostgreSQL license does not have a termination clause, you added that. I see that you are trying to use the PostgreSQL license as the basis and simply add the patent clause onto it, but it fundamentally changes the license.
I hope you can look at the Apache 2 patent grant as a better clause- or even adopt something like Google's Additional IP License found here- https://www.webmproject.org/license/additional/, which doesn't modify the open source license but instead adds an additional grant as a separate license.
Supabase is doing great work, thank you!
Can you acquire atlasgo too, or is that still on the secret roadmap?
we will have something to announce in this space within a few months
(if the atlasgo team are reading this feel free to reach out too)
This is highly unprofessional.
Have them look at, and consider just adopting the MS-PL?
https://opensource.org/license/ms-pl-html
Microsoft used it a ton, until they eventually just made everything open-source fall under the MIT license.
Some people will still be angry about it (I got a downvote for just mentioning it elsewhere on this thread) but as the person who built your software, you have every right to license your software as you deem necessary. There is a cost to what you've built and you have no true obligation to give everything for free.
On that note, as far as I can remember the MS-PL is OSI approved already.
Apache 2.0 has a better patent clause - against hostile IP claims, so tax dispute is not terminate the OrioleDB license:
"If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed."
https://opensource.org/license/apache-2-0
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.
MPLv2 has a stronger version of this (I also personally prefer it in general to Apache-2.0 if you can't stomach GPLv3).
https://news.ycombinator.com/item?id=45200014
A shield for Supabase, not for us
Does the current license even allow for friendly forks, or redistribution?
It starts off nice with the usual:
> PERMISSION TO USE, COPY, MODIFY, AND DISTRIBUTE THIS SOFTWARE AND ITS DOCUMENTATION FOR ANY PURPOSE, WITHOUT FEE, AND WITHOUT A WRITTEN AGREEMENT IS HEREBY GRANTED
.. but then there's the:
> HEREBY GRANTS A (..) LICENSE TO UNITED STATES PATENT NO. 10,325,030 TO MAKE, HAVE MADE, USE, HAVE USED, OFFER TO SELL, OFFERED TO SELL, SELL, SOLD, IMPORT INTO THE UNITED STATES, IMPORTED INTO THE UNITED STATES, AND OTHERWISE TRANSFER THIS SOFTWARE
.. which to me seems to be missing some kind of "modify" clause? Sure, it seems like you're allowing me to distribute it as-is the way a store like Amazon distributes boxes, but what happens when I start modifying the code and distributing those modifications? Is it still "this software", or has it become a derivative? Is the license I get to that patent even sublicensable? What happens to users of a fork when the forkee sues Supabase: do they also by extension lose their patent license?
The GPLv2, for example, has a clause stating that "Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor" which makes it very clear what happens. If you're adding a poison pill to open-source code, you really shouldn't be this sloppy: it should be painfully obvious to every reader what the implications are, or nobody will ever risk using it.
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). All of them still allow you to make modifications but they do not guarantee that some other patents will not be infringed by your modifications and open you up to patent lawsuits (even from the same entity).
Assuming a lawyer wrote this, this is probably part of the reason for it. But it does feel a little sloppy, a separate patent license with clear terms would probably be more preferable.
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.
The difference is that the license is terminated by ANY litigation against Supabase - e.g. if you sue them for breach of contract completely unrelated to the software.
Use as a shield would mean limiting it to patent litigation against a user of the software.
It also only covers litigation against Supabase - it does not provide a shield against litigation against OrioleDB users.
Or litigation from a future license violation
Sounds like the MS-PL which Microsoft used to use but switched to MIT. MS-PL is basically MIT but cover your butt against patent litigation.
You need to read the text more carefully -- the license terminates for any litigation against Supabase at all. Hypothetically, a former employee of Supabase suing them for some employee rights violation would no longer be allowed to use the software, which is not the case for any other OSI-approved license with patent shields.
The MS-PL has the fairly standard reactive patent shield that only activates for patent-related litigation for the specific software under the license and is kind of similar to the language in Apache 2.0, MPLv2, and GPLv3.
But they have now switched to Apache 2.0, so crisis averted.
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.
> 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.
How'd you arrive at this conclusion? The stuff in the body of the patent can be expected to be 99.99% of widely known stuff, always.
What counts is that something new is disclosed, and that is what the claims cover.
A description of a patent must be enabling: it must tell someone ordinarily skilled in the art enough to reproduce the claimed invention. Gesticulating at "you could find a bunch of the simpler steps in earlier research papers" is not good enough.
How far attorneys go to make sure a patent description is wildly varying (I remember some of my earlier ones take some time to describe what a CPU and program are...) but it's best to error on the side of caution and describe well known techniques. Otherwise, you might spend time arguing in future litigation about whether the average software engineer in 2015 knew how to do a particular thing.
True. For some of my patents, the write ups make clear that the attorneys didn’t really understand how things worked. At some point, reviewing these things, you have to say, “Yea, okay, close enough,” and sign off on it.
100% truth. People complain of AI Slop, but patent legalese Slop is 100x worse and has been going on for 100years. Absolute garbage
You're being entirely unfair to Supabase here. Research is important, but there is a reason why the USPTO has developed substantial case law around Reduction to Practice, everything is built on prior work, so to say there is nothing novel about actually building displayed working system from parts is factually inaccurate.
https://en.wikipedia.org/wiki/Reduction_to_practice
To add to your point: we didn’t file the patent. we acquired it (at a considerable cost) and we are working to make it freely available
https://news.ycombinator.com/item?id=45196771
Yeah, huge props here. There's a contingent on HN that seems to assume that almost any action by a company is done in bad faith. I dislike all of the shady stuff that happens, but that's why we should celebrate when companies are doing awesome things.
This is all positive. Super appreciate what you folks have done. It's clearly hard, well intentioned, and thoughtfully executed.
Mad respects.
People might say that the company is doing it for good will, but that is the point, it is better to get the good will of the users by actually helping them instead of being like thousands of other companies which don't even do that. It is a nuanced topic but I feel like we should encourage companies which do good period. (like silksong / team cherry in gaming) etc.
I will look further into this now :p thanks!
> Burn the patent
that's ... that's what they are doing by making it freely available, no?
this helps anyone who is covered by the patent because they are (a bit better) protected from other patent trolls (and from other IP litigation)
A US Patent can not be ever open-sourced. In legal and logical terms, those are on the pretty much opposite sides of the spectrum.
The closest that comes to mind is "Free Nestlé bottled water".
why? the usual OSI licenses all work through copyright, and through conditional granting of rights (hence the name license)
for a parent granting irrevocable royalty-free usage rights to anyone is equivalent to putting it into the public domain, no?
both copyright and a patent grants exclusive rights to the rightsholder (right to perform, modify, or in case of patents to use the invention in the way covered by one of the claims), and the rightsholder is free to include more persons in the group of authorized users (ie. extend the rights to others, and can do so conditionally - hence the Apache2 patent grant)
can you please explain where my understanding is incorrect or missing something? thanks!
Copyright and patents are very different beasts.
For example there a lot of ways to use the so-called priority of the US patent to file other patents, including elsewhere in the world.
US Americans sadly often forget that the majority of the planet is not the USA. Here in Thailand, US and EU pharma companies have managed to get patents on 15 year old basic stuff like anti-histaminic meds. "Oh, but the system of limited monopoly in the US worked for us?". Yeah. But in Europe, the cost per pill is somewhere around $0.08. In Europe it's about $0.02. In Thailand it's $0.80 because Zyrtec managed to file a patent here re-using the priority of the US patent. And wage-adjusted in Thailand the cost per pill is about $15 per pill. You better don't have an allergy over here. So: Patents can have long-term consequences.
Back to IT: Have a look at the whole patent troll industry. The biggest chunk of junk patents that they bought are coming from "we will not do any harm" owners/filers. A lot can happen in 20 years.
Ah, I completely support your righteous anger against the tragicomedy of US "IP colonisation", though note that it has not much to do with my comment about the possibility of an open source patent.
The fact that most of the world was just laying down belly up to accept the negative consequences of the ridiculous cottage industry of churning out patents "for later" is truly enraging if someone gets to see how little value it produces. (It's very convenient for large conglomerates, VC fueled startups, and ... that's it.)
When it comes to specifics, ie. with pharma, it's hard to really disentangle the mess from other ugly facts, like the post-WWII global economy which and the very misregulated US healthcare industry (R&D including).
The US is subsidizing R&D for the world, because the other rich countries have sane "collective bargaining", but this leaves the small not so rich markets out in the fucking cold, because they have a weak bargaining position (market access doesn't worth that much to pharma companies) and also usually no internal R&D (so no local companies filing for these trivial parents). But because of all this in effect the world is buying R&D at the worst price!
(Though of course the picture is more complicated than this, but R&D is definitely waaay too inefficient in the US, but also all over the world too.)
Not really? You can build on top of their code, but as far as I can tell, you can’t build your own thing separately.
From the article:
The intention of OrioleDB is not to compete with Postgres, but to make Postgres better. We believe the right long-term home for OrioleDB is inside Postgres itself. Our north star is to upstream what’s necessary so that OrioleDB can eventually be part of the Postgres source tree, developed and maintained in the open alongside the rest of Postgres.
OK, just saved to the file cringespeak.txt:
"Our north star is to..."
:)
This comment makes no sense. They're actively open sourcing the patent and trying to get it upstream into Postgres. They purchased another company to get this patent, and they're spending a lot of money on lawyers to figure out how to release it to the community.
Call out shady shit when companies do shady things, but the sentiment behind this comment seems to be looking for reasons to bee outraged instead of at what's actually being done.
If companies get evicerated every time they try to engage with the community they'll stop engaging. We should be celebrating when they do something positive, even if there are a few critiques (e.g. the license change call out is a good one). Instead, half the comments seem like they're quick reactions meant to stoke outage.
Please have some perspective - this action is a win for the community.
I stated I see the good intentions.
I am "owner" of a bunch of patents, too, and some have actually been proven their test of time by after years having been re-invented (better: "parallel-invented later in time") elsewhere in the open source world.
But in my value system one does not do press releases saying "HELLO! We have decided not to do something evil!".
They could have done the very same thing done quietly to make clear there is no hidden agenda.
"Look, we hold this trivial patent on the open source ecosystem. No no no, all will be fine. No, no, we will not pick up the phone should Broadcom call us one day."
Yay. \o/
> 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.
[0]: https://github.com/orioledb/orioledb/commit/44bab2aa9879feb7...
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?
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.
I strongly dislike the idea of patenting data structures.
fwiw, this is not our m.o. - oriole was under development before we took on the maintenance/development.
Our goal now is to ensure that it’s as F/OSS as possible given the pre-existing conditions
OrioleDB is new to me.
According to the docs, it “uses Postgres Table Access Method (TAM) to provide a pluggable storage engine for PostgreSQL. […] Pluggable Storage gives developers the ability to use different storage engines for different tables within the same database. Developers will be able to choose a storage method that is optimized for their specific needs: some tables could be configured for high transactional loads, others for analytics workloads, and still others for archiving.”
https://www.orioledb.com/docs
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
Thanks for verifying the benchmarks. We’re close to a full RC, aiming for December
Just to add: if anyone wants to contribute (beyond code) benchmarking and stress-testing is very helpful for us
I assume you get this a lot, but how much patching is left in PG 18?
We are tracking the patches here:
https://www.orioledb.com/docs#patch-set
The actual storage engine is written as an extension - these patches are mostly to improve the TAM API. If these are accepted by the community then it should be simpler for anyone to write their own Storage extensions.
I think (correctly) it will take a lot longer to upstream the extension - the PG community should take a “default no” attitude with big changes like this. Over time we will prove its worthiness (hopefully beyond just supabase - it would be good to collaborate with other Postgres providers)
OK, so basically no big change with PG 18, and for the time being, one needs to basically your own Postgres?
Would be really nice with a pgdg package, as this is definitely the kind of thing I would want to test in a separate cluster :-)
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?
[0] https://github.com/orioledb/orioledb?tab=readme-ov-file#orio...
[1] https://news.ycombinator.com/item?id=30462695 (2022)
I haven't explicitly tested how it handles TOASTed column's, but since there is an upcoming RC I will try it out next time. I don't generally like using JSONB/text columns for very large rows as they have other performance problems on the DB like causing lots of WAL write overhead.
In term of other workloads it might not be great for, all my testing has shown a great improvement in every workload I have thrown at it.
OrioleDB looks interesting but the with the storage changes, the issue will be the compatability with other extensions. pg_search (paradedb), timescale come to mind.
We have seen this issue with YugabyteDB, and their integration off RocksDB as the storage engine for postgresql.
As far as I know, you can run heap and orioledb tables side by side in the same system, so I don’t see a problem using heap-based extensions like timescale together with orioledb. ( of course timescale doesn’t support OrioleDB storage yet, but they can run in parallel. )
and many extensions (e.g. postgis) already work fine with OrioleDB storage.
I did not know you could patent data structures like that.
IP owners often play the game of “patent what you can, threaten with the rest.” So you might not be able to strictly patent the way data is laid out, but specific, novel algorithms that update or manipulate that layout and improve what was possible before? Those can be understood as key steps of an “innovative process”—and courts have been willing to uphold process claims, especially when tied to what they understand are genuine technical improvements. Fighting even a marginal patent usually means a long, expensive slog with plenty of downside risk.
IANAL nor a patent judge, but this is my understanding after watching the space for some years.
At least this is how it works in the US. And in the US algorithms are (unfortunately) patentable. That is not the case in all countries.
Correct.
But at the same time, globalization means legal mandates are increasingly extra-territorial in scope and impact. U.S. patent law affects anyone whose products touch the American market.
Similarly, CCPA/CPRA and GDPR reach far beyond their nominal geographic borders.
You can in the US. Not so much in the rest of the world.
That's juridiction dependent. Europe didn't allow such a thing last time I checked. But lobbying to do so as been recurrent on this topic, just like putting governmental backdoor everywhere. They will try until it passes. There should be legal penality for such a stubborn will to destroy civil liberty. At least in this case they can't play the card "think of the children, nazi pedophiles use this".
Software patents is such an americanism. In this case, I prefer Chinese approach to ignoring patent law altogether.
In general China has historically taken any sort of intellectual property rights and outright theft very differently then the rest of the developed world.
When you're in manufacturing, ignore IP
When you're in IP, bang on IP
That's just the path for all who do this stuff. America seems culturally to like IP (everyone saying that copyright law is paramount and LLMs should be stopped, etc.) but that's just recent history.
That simply kills innovation and dries up funding for research.
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.
> 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.)
https://itif.org/publications/2024/09/16/china-is-rapidly-be...
https://www.economist.com/science-and-technology/2024/06/12/...
State-sponsored industrial espionage isn't the same as innovation.
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.
Probably because DeepSeek creators were afraid government would just come and take it from them. The only solution was to open source it which is kind of a big middle finger to the Chinese government.
Supabase consistently delivering massive value to the postgres ecosystem
> 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-...
For what it's worth, this does appear to be just a temporary situation, as mentioned in that linked document and in code comments e.g. https://github.com/orioledb/orioledb/blob/7f3b3a9a8e195ba31f...
that message was put there 2 years ago. soon may not be coming.
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).
In contrast, typically it's not hard to resolve the concurrency problems of writing transactions using explicit row-level and advisory locks, while REPEATABLE READ is enough for reporting. Frankly speaking, during my whole career, I didn't see a single case where SERIALIZABLE isolation level was justified.
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.
In the case of SERIALIZABLE you do need to retry in case of conflict, but usually the serialization anomalies can be limited to a reasonably fine level. And an explicit retry feels safer than risking a livelock situation when there is contention.
Exclusion constraints should work well for this case. On any transaction isolation level.
https://www.postgresql.org/docs/current/ddl-constraints.html...
That's indeed the first thing you would want to try. In this case these time ranges can repeat according to a formula, like a cron job for example.
An exclusion constraint needs concrete values to compare, but here we can't pre-compute and index every future value (there are infinitely many)
We solve a diophantine equation for this check (if there is a solution to Ax - By = 0, then formulas A and B can conflict at some point)
This seems like a fascinating problem domain! I'm incredibly curious what product you're working on - if you're taking this much attention to detail on recurring events, it seems like it's a step beyond most scheduling systems I've seen.
Heck, https://www.sciencedirect.com/science/article/pii/S147466701... and https://www.amazon.com/Declarative-Models-Concurrent-Cyclic-... seem to indicate this is still an area of active research. And, to your point, almost certainly too complex to try to encode into a Postgres index - that would be a paper-worthy project unto itself!
(I've had to implement the naive approach here, which nested-loops over dates and rules and finds ones that might conflict. Definitely not meant to scale, and would be a nightmare if not at a date-level granularity!)
No pressure to share, but would love to learn more!
It's a scheduling system in the medical field where recurring events can happen in a particular room, this might be every N days at a particular time, or every three weeks on Tuesday and Friday between some start date and some end date.
I'm not entirely familiar with the literature, so we did some simplifications to keep it manageable, and it's very possible there might be a better approach!
We model the events generated by our recurring rules as intervals [SA+n*A, SA+n*A+DA), where A is a constant integer number of days (e.g. A=3*7 for an event on Tuesday every 3 weeks), SA is the start date, and DA is the duration of an event (... which can be >24h to make things more interesting). It might continue recurring forever, or it might stop by some end date.
Now if you have two of these recurring events with periods A and B, you can think of each of them as a periodic function, and the combination of them will have a period equal to LCM(A, B). So we could check everything modulo LCM(A, B) once, and that would hold infinitely far forward.
But actually, we can do even better by taking the difference Δ=SA-SB mod GCD(A, B). You can sort of think of it as the closest approach between these two recurring events. If that's less than DA or more than the GCD-DB, these events are eventually going to overlap. There's some extra details to check whether overlap happens before either end date (if any), but that's the idea in a nutshell.
---
Where it gets really interesting is when you introduce timezones and daylight savings time (DST). Now a day is not always 24h, so there isn't a nice [SA+n*A, SA+n*A+DA) at regular intervals, and we can't naively work modulo the LCM or GCD anymore.
But we can notice that the days of the year on which a DST transition falls generally follow simple rules, and would repeat every 28 years (actually every 400 years due to leap years). In practice for a given timezone, for example CEST, there are only 14 unique days of the year on which the DST transitions can fall, and it repeats after a full period.
So if we want to check for overlap, we can treat those DST transition days as special cases, and all the time intervals in between DST transition days look locally "UTC-like" (time doesn't jump forward or backwards, if we ignore leap seconds), so the previous formula continues to work on all of these.
But at some point things become a little messy, so we did some simplifications =)
My napkin math suggests the size of the supercycle when you take two recurring events A and B with periods < 365 days and the 400 year cycle for DST transition can be about a hundred thousand years in the worst case.
But considering that timezones and daylight savings time are fundamentally political decisions, and that the IANA tzdata file is updated regularly, there is not much sense in applying the current rules thousands of years into the future! So we check at most 400 years ahead, and we consider that when timezones are involved, the overlap check is best effort and we prepare for the fact that it could miss a DST transition – no matter what math we do, a country could change the rules at any time, and a day that used to be 24h could now be 25, 22:30, or even skipped entirely, invalidating all past assumptions.
Thank you so much for sharing this! That sounds like an equally fun and headache-inducing problem indeed!
The idea that someone could book a room for 400 years of consistency guarantees is somewhat hilarious, yet absolutely the kind of thing that would check a box in a regulated environment like healthcare!
It does speak to a larger issue I see quite often, which is that capturing structured intent as of the time an event is created, with the context that led to that decision, is incredibly hard to model. Because no matter what, something about the system will change, like daylight savings time or assumptions around resource/room availability, in an unpredictable way such that the data that had been used to drive a confident evaluation of lack-of-conflict at insertion time, is now insufficient to automatically resolve conflicts.
There's no single way to solve this problem - in a way, "reinterpreting intent" is why programming is often equal parts archaeology and anthropology. Certainly gives us very interesting problems to solve!
To circle it back to the original conversation: the better our databases are at handling large volumes of written data, the more context we can capture around insertion-time intent in an easy-to-query way, and the better we'll be at adapting to unforeseen circumstances!
I use SERIALIZABLE on a database for which I have very low writer concurrency (I can count the total writer connections on 1-2 hands) and where I really, really, really don’t want to deal with the fallout if a transaction commits and results in an impossible state.
I use MySQL, not Postgres, for this application (for better or for worse), and I can absolutely generate a bad state if I drop MySQL to a level below SERIALIZABLE — I’ve tried it. (Yes, I could probably avoid this with SELECT FOR UPDATE, but I don’t trust MySQL enough and I get adequate performance with SERIALIZABLE.)
To make SERIALIZABLE work well, I wrap all the transactions in retry loops, and I deal with MySQL’s obnoxious reporting of which errors are worthy of retries.
(Aside from bad committed states, I’ve also seen MySQL return results from a single straightforward query that cannot correspond to any state of the table. It was something like selecting MIN, MAX and COUNT(*) from a table and getting min and max differing and count = 1. It’s been a while — I could be remembering wrong.)
been using select for update for many years now, in production. never had any issues. (MariaDB)
Eh. If you care about performance enough to use OrioleDB you probably also want to avoid SERIALIZABLE.
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.
"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, at worst it's an attempt for Supabase to provide themselves unlimited indemnity through the guise of a community project. It means the moment you sue Supabase for anything. Contract dispute, IP, employment, unrelated tort you lose the license. They could lose your data and if you try do anything about it they can immediately counter sue for a license violation. Using the brand of the postgres license to slip this in is pretty wild.
OrioleDB looks like a promising project and undoubtedly an great contribution from Supabase but it's not open source or really usable by anyone with this license.
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
I recall Facebook had a similar rider on the React license for many years until eventually removing it. It’s visually similar to the Apache2 patent clause but not scoped to just the licensed software use
Isn’t this just Apache 2-style permissive licensing?
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.
The graphs for OrioleDB looks very impressive. Can someone give a counter argument to switching to this?
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.
(Opinions are my own, not of my employer)
I think that "under review" claim is doing some very heavy lifting, especially when it relates to their changes to index tuple lifecycle management. The patches that have been submitted are unlikely to get committed in full anytime soon, even after substantial changes to the patches' designs.
PostgreSQL just has not been designed for what OrioleDB is doing, and forcing OrioleDB's designs into PostgreSQL upstream would a lot of (very) sharp edges that the community can't properly test without at least a baseline implementation - which critically hasn't been submitted to upstream. Examples of these sharp edges are varsized TIDs, MVCC-owning indexes, and table AM signalled index inserts.
There are certainly ideas in OrioleDB's designs that PostgreSQL can benefit from (retail index tuple deletion! self-clustering tables!), but these will need careful consideration in how this can be brought into the project without duplicating implementations at nearly every level. A wholesale graft of a downstream fork and then hoping it'll work out well enough is just not how the PostgreSQL project works.
Oh this dampens my expectations, I was under the wrong impression that it will stabilise outside of Postgres before it is merged.
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).
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-poi...), and pages are read lock-less (https://www.orioledb.com/docs/architecture/overview#page-str...). Additionally, tree navigation for simple data types skips both copying and tuple deforming (https://www.orioledb.com/blog/orioledb-fastpath-search).
According to all of the above, I believe OrioleDB still wins in the case of secondary key lookup. I think this is indirectly confirmed by the results of the TPC-C benchmark, which contains quite a lot of log of secondary key lookups. However, this subject is worth dedicated benchmarking in the future.
It would be interesting to see how OrioleDB does with more OLAP-like loads. From when I spent a lot of time benchmarking this, the indirect index design was _the_ main reason why MySQL+InnoDB was losing significantly to Postgres on TPC-H (well, DBT-3).[1] There was a lot of working around it with covering indexes etc..
Of course, the flip side of the coin is that if you do an UPDATE of a row in the presence of a secondary index, and the UPDATE doesn't touch the key, then you don't need to update the index(es) at all. So it really depends on how much you update rows versus how often you index-scan them IME.
[1] TPC-H doesn't have difficult enough queries to really stress the planner, so it mattered comparatively less there than in other OLAP work.
Thank you, that would be on the TODO list.
That’s how regular Postgres b-tree indexes work too.
I'll take a [citation needed] on that one.
https://www.postgresql.org/docs/current/indexes-index-only-s...
This is why Postgres b-tree indexes offer CREATE INDEX (indexCol1, indexCol2, ...) INCLUDE (includeCol1, includeCol2, ...). With INCLUDE, the index will directly store the listed additional columns, so if your query does `SELECT includeCol1 WHERE indexCol1 = X AND indexCol2 > Y`, you avoid needing to look up the entire row in the heap, because includeCol1 is stored in the index already. This is called a "covering index" because the index itself covers all the data necessary to answer the query, and you get an "index only scan" in your query plan.
The downside to creating covering indexes is that it's more work for Postgres to go update all the INCLUDE values in all your covering indexes at write time, so you are trading write speed for increased read speed.
I think it's quite typical to see this in SQL databases. SQLite behaves the same way for indexes; the exception is that if you create a WITHOUT ROWID table, then the table itself is sorted by primary key instead of by ROWID, so you get at most 1 index that maps directly to the row value. (sqlite docs: https://sqlite.org/withoutrowid.html)
That link directly contradicts what you are saying.
> This means that in an ordinary index scan, each row retrieval requires fetching data from both the index and the heap.
Note that it says _index and the heap_. Not _index and the primary index and the heap_. (For a B-tree-organized table, the leaf heap nodes are essentially the bottom of the primary index, so it means that to find anything, you need to follow the primary index from the top, which may or may not entail extra disk accesses. For a normal Postgres heap, this does not happen, you can just go directly to the right block.)
Index-only scans (and by extension, INCLUDE) are to avoid reaching into the heap at all.
> The downside to creating covering indexes is that it's more work for Postgres to go update all the INCLUDE values in all your covering indexes at write time, so you are trading write speed for increased read speed.
For updates, even those that don't touch INCLUDE values, Postgres generally needs to go update the index anyway (this the main weakness of such a scheme). HOT is an exception, where you can avoid that update if there's room in the same heap block, and the index scans will follow the marker(s) you left to “here's the new row!” instead of fetching it directly.
Ah gotcha. My understanding of the heap reference was that heap lookups involve traversing a heap-like tree data structure, not a direct link to a specific leaf page.
Based on the limited description of OrioleDB I understand it works like SQLite WITHOUT ROWID, actually storing the row tuple in the primary key b-tree, but I didn’t go read the code
It's confusing nomenclature, but Postgres' “heap” is not a heap (B-tree) data structure. It is just a bunch of blocks all on the same level, similar to how the “heap” in an operating system (as opposed to the stack) is.
Notably, you can have a Postgres table without a primary key at all, not even an implicit one.
> Based on the limited description of OrioleDB I understand it works like SQLite WITHOUT ROWID, actually storing the row tuple in the primary key b-tree, but I didn’t go read the code
This is my understanding of OrioleDB as well.
Yep, regular PostgreSQL indexes point to a heap location (block number + offset). And it is the same for primary and secondary indexes.
Non go when it includes a poison pill.
https://news.ycombinator.com/item?id=45200014
It is time to realize that open source drives innovation.
Legal shield? So once again people have to do manual legal work for something that can be taken for granted in any (L)GPL* software.
We should start counting the times a permissive-licensed software needs this kind of protection, and then wonder what is the difference between all this effort and just going GPL.
You don't need to hang onto hopes and public shaming until someone else does the hard part.
Still, kudos for the grant.
Is OrioleDB just PostgreSQL but with some underlying modifications for cloud environments?
How does it compare with Neon DB?
"The differences between OrioleDB and Neon" ( June 20, 2025 )
https://www.orioledb.com/blog/orioledb-neon-differences
The "cloud environments" part sounds like marketing fluff. "The cloud" is just someone else's servers after all. There's nothing special about it.
That’s like saying a chair is just a tree that has been modified. Technically true, practically there are some very specific differences.
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.
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.
I agree that all of those things could be true, but I haven't read anything that indicates any special dependency on or knowledge of proprietary cloud systems. As far as I can tell, it's just going to use whatever disk/CPU you give it?
> There's nothing special about it
Wait when you need to manage a bunch of servers yourself. Unfortunately, the solutions available are complex, and not something where you can simply points something to a server, or VPS, and have a quick total controlled kernel level solution. K8, sure, but even that is not on the same level. And when you then need to manage DB's, your often placing those outside K8. Most scalable solutions like CRDB (10m pay, required yearly "free" license approval), Yugabyte(half broken), TiDB ... have their own issues and again, do not tie into a complete managed cloud experience.
In this case, it seems to refer to their support for S3-compatible object storage as for persistence.
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.
It’s a different storage engine for Postgres
So if someone wanted to implement this in MySql, what would the legal ramifications be?
Well, nm, pretty clear path now:
https://github.com/orioledb/orioledb/commit/44bab2aa9879feb7...
Love you supabase
Honestly so amazing! Supabase doing great work as always
[dead]
> OrioleDB implements default 64-bit transaction identifiers
RDS support when