HN Reader

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.

> OrioleDB implements default 64-bit transaction identifiers

RDS support when

Software patents is such an americanism. In this case, I prefer Chinese approach to ignoring patent law altogether.

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

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

Love you supabase

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 did not know you could patent data structures like that.

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

It is time to realize that open source drives innovation.

I strongly dislike the idea of patenting data structures.

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.

The graphs for OrioleDB looks very impressive. Can someone give a counter argument to switching to this?

Non go when it includes a poison pill.

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

Is OrioleDB just PostgreSQL but with some underlying modifications for cloud environments?

How does it compare with Neon DB?

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

So if someone wanted to implement this in MySql, what would the legal ramifications be?

Supabase consistently delivering massive value to the postgres ecosystem

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

Honestly so amazing! Supabase doing great work as always