public inbox for [email protected]help / color / mirror / Atom feed
pgvector as standard PostgreSQL feature? 3+ messages / 3 participants [nested] [flat]
* pgvector as standard PostgreSQL feature? @ 2025-03-19 06:47 Sebastien Flaesch <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Sebastien Flaesch @ 2025-03-19 06:47 UTC (permalink / raw) To: pgsql-general Hello, I am looking at pgvector, pgvectorscale, pgai extensions. Other DB engines support built-in vector types. Is there a plan to get pgvector's types (vector, halfvec, sparsevec, bit) implemented as native built-in data types like json/jsonb ? Side note: I have some doubts about these type names, especially "bit" ... why not "bitvec"? Seb ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgvector as standard PostgreSQL feature? @ 2025-03-19 08:19 Christophe Pettus <[email protected]> parent: Sebastien Flaesch <[email protected]> 0 siblings, 1 reply; 3+ messages in thread From: Christophe Pettus @ 2025-03-19 08:19 UTC (permalink / raw) To: Sebastien Flaesch <[email protected]>; +Cc: pgsql-general > On Mar 19, 2025, at 07:47, Sebastien Flaesch <[email protected]> wrote: > > Is there a plan to get pgvector's types (vector, halfvec, sparsevec, bit) implemented as native built-in data types like json/jsonb ? (I'm speaking just for myself here.) I would not base any plans on this functionality being available in the PostgreSQL core in the near future (and by "near future," I mean the next five years). 1. You list three different extensions with overlapping functionality, and that's a good sign that there isn't consensus on what the features that would be offered in core should be. 2. Adding a type to the core distribution (or even to contrib/) creates a maintenance burden on the core developers, and that's not something assumed lightly. Once a type is in core, it (almost) never can be removed, and the more specialized the type and detailed the implementation, the greater the risk that the developers who know and care about it won't be available in the future. Search the archives for a discussion of the "money" type for what happens when a type added to core starts becoming ill-supported... and "money" isn't anywhere near as complex as vector functionality. 3. PostgreSQL is designed to have a rich ecosystem of extensions. The ability to add this kind of functionality in an extension is exactly what distinguishes PostgreSQL from many other RDBMS systems. There's no burning need to add functionality like this to core. It is true that hosted environments take time to adopt new extensions (although AWS RDS has supported pgvector for nearly two years now), but that's not in itself a reason to move things into core. > Side note: I have some doubts about these type names, especially "bit" ... why not "bitvec"? BIT and BIT VARYING are the SQL standard names for these types. ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: pgvector as standard PostgreSQL feature? @ 2025-04-06 20:59 Merlin Moncure <[email protected]> parent: Christophe Pettus <[email protected]> 0 siblings, 0 replies; 3+ messages in thread From: Merlin Moncure @ 2025-04-06 20:59 UTC (permalink / raw) To: Christophe Pettus <[email protected]>; +Cc: Sebastien Flaesch <[email protected]>; pgsql-general On Wed, Mar 19, 2025 at 3:20 AM Christophe Pettus <[email protected]> wrote: > > > > On Mar 19, 2025, at 07:47, Sebastien Flaesch <[email protected]> > wrote: > 2. Adding a type to the core distribution (or even to contrib/) creates a > maintenance burden on the core developers, and that's not something assumed > lightly. Once a type is in core, it (almost) never can be removed, and the > more specialized the type and detailed the implementation, the greater the > risk that the developers who know and care about it won't be available in > the future. Search the archives for a discussion of the "money" type for > what happens when a type added to core starts becoming ill-supported... and > "money" isn't anywhere near as complex as vector functionality. > > 3. PostgreSQL is designed to have a rich ecosystem of extensions. The > ability to add this kind of functionality in an extension is exactly what > distinguishes PostgreSQL from many other RDBMS systems. There's no burning > need to add functionality like this to core. > > It is true that hosted environments take time to adopt new extensions > (although AWS RDS has supported pgvector for nearly two years now), but > that's not in itself a reason to move things into core. > Managed offerings are the norm now, so there really is big difference between core and non-core extension, unless your extension is popular enough (as pgvector is) to be supported across the major providers or only requires SQL to deploy. Your point about core is valid, but there is definitely a squeeze on that is preventing ecosystem expansion, don't know what the solution is though. merlin ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-04-06 20:59 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-03-19 06:47 pgvector as standard PostgreSQL feature? Sebastien Flaesch <[email protected]> 2025-03-19 08:19 ` Christophe Pettus <[email protected]> 2025-04-06 20:59 ` Merlin Moncure <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox