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.

(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)

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

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 shield for Supabase, not for us

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.

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.

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

That simply kills innovation and dries up funding for research.

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?

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.

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".

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

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)

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.

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...

Eh. If you care about performance enough to use OrioleDB you probably also want to avoid SERIALIZABLE.

"The differences between OrioleDB and Neon" ( June 20, 2025 )

https://www.orioledb.com/blog/orioledb-neon-differences

It’s a different storage engine for Postgres

The "cloud environments" part sounds like marketing fluff. "The cloud" is just someone else's servers after all. There's nothing special about it.

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.

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).