Re: pgvector as standard PostgreSQL feature?

> On Mar 19, 2025, at 07:47, Sebastien Flaesch <sebastien.flaesch@4js.com> wrote:
>
> Is there a plan to get pgvector's types (vector, halfvec, sparsevec, bit) implemented as native built-in data types
likejson/jsonb ? 

(I'm speaking just for myself here.)  I would not base any plans on this functionality being available in the
PostgreSQLcore 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
consensuson 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,
andthat's not something assumed lightly.  Once a type is in core, it (almost) never can be removed, and the more
specializedthe type and detailed the implementation, the greater the risk that the developers who know and care about
itwon't be available in the future.  Search the archives for a discussion of the "money" type for what happens when a
typeadded 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
extensionis exactly what distinguishes PostgreSQL from many other RDBMS systems.  There's no burning need to add
functionalitylike this to core. 

It is true that hosted environments take time to adopt new extensions (although AWS RDS has supported pgvector for
nearlytwo 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.