Hacker News new | ask | show | jobs
by netcraft 897 days ago
So approximately 0% chance I could use this on AWS RDS or Aurora correct?

Still, very impressive

2 comments

This extension is licensed under the Business Source License[0], which makes it incompatible with most DBaaS offerings. The BSL is a closed-source license. Good choice for Lantern, but unusable for everyone else.

Some Postgres offerings allow you to bring your own extensions to workaround limitations of these restrictive licenses, for instance Neon[1], where I work. I tried to look at the AWS docs for you, but couldn't find anything about that. I did find Trusted Language Extensions[2], but that seems to be more about writing your own extension. Couldn't find a way to upload arbitrary extensions.

I will add that you could use logical replication[3] to mirror data from your primary database into a Lantern-hosted database (or host your own database with the Lantern extension). This obviously has a couple downsides, but thought I would mention it.

[0]: https://github.com/lanterndata/lantern/commit/dda7f064ca80af...

[1]: https://neon.tech/docs/extensions/pg-extensions#custom-built...

[2]: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Postg...

[3]: https://www.postgresql.org/docs/current/logical-replication....

Likely as an extension eventually. I know RDS has a variety of postgres extensions you can use. Pg_vector is supported, so likely lantern could get support as well.

[1] https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Postg...

Unless AWS is going to buy a license, which is probably going to cost them a ton of money, I don't seem them offering Lantern given its licensed under the Business Source License, which is nasty for cloud providers.

AWS is also a big proponent of pgvector, so it is more likely they would put more money into that, in my non-expert opinion.

Adding to this, the article the GP comment has linked to is for Trusted Language Extensions, which would allow AWS users to run extensions that aren't "officially" installed on RDS

however, since Latern is written in C++, it is not a Trusted Language for Postgres. If they instead used Rust (for example), then it would theoretically be able to be used with RDS, since Rust is now a Trusted Language on RDS: https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-rd...

My understanding is Trusted Language Extensions refer to extensions written in PL/Rust - a Postgres extension mechanism to write user defined functions and use them in SQL queries.

PL/Rust is a more performant and more feature-rich alternative to PL/pgSQL, which is the traditional UDF scripting language for Postgres.

Building a vector index (or any index for that matter) inside Postgres is a more involved process and can not be done via the UDF interface, be it Rust, C or PL/pgSQL.

So, I think even if Lantern was written in Rust, it would not be a Trusted Language Extension under this definition.

(disclosure, i work at supabase and have been developing TLEs with the RDS team)

Trusted Language Extensions refer to an extension written in any trusted language. In this case Rust, but it also includes: plpgsql, plv8, etc. See [0]

> PL/Rust is a more performant and more feature-rich alternative to PL/pgSQL

This is only partially true. plpgsql has bindings to low-level Postgres APIs, so in some cases it is just as fast (or faster) than Rust.

> Building a vector index (or any index for that matter) inside Postgres is a more involved process and can not be done via the UDF interface, be it Rust, C or PL/pgSQL

Most PG Rust extensions are written with the excellent pgrx framework [1]. While it doesn't have index bindings right now, I can certainly imagine a future where this is possible[2].

All that said - I think there are a lot of hoops to jump through right now and I doubt it's worth it for your team. I think you are right to focus on developing a separate C extension

[0] TLE: https://supabase.com/blog/pg-tle

[1] pgrx: https://github.com/pgcentralfoundation/pgrx

[2] https://github.com/pgcentralfoundation/pgrx/issues/190#issue...