Feature: Spatial, full-text search, and vector support
First of all, great work on pgrust. Getting a Rust rewrite of PostgreSQL to the point where it passes the PostgreSQL regression and isolation tests is extremely impressive.
One area that I think would make pgrust substantially more useful for real-world applications is support for some of the most important PostgreSQL extensions, particularly:
- Spatial: PostGIS
- Search:
pg_search (ParadeDB / BM25)
- Vector:
pgvector
Why these three?
Together, these extensions cover three increasingly common workloads that applications currently depend on PostgreSQL for:
1. Spatial / PostGIS
PostGIS provides PostgreSQL with spatial data types, spatial functions, and spatial indexing.
This is particularly important for applications requiring:
geometry / geography
- latitude/longitude queries
- distance calculations
- radius / proximity searches
- spatial joins
- polygons and delivery/service areas
- spatial indexes such as GiST
- functions such as
ST_DWithin, ST_Distance, ST_Contains, ST_Intersects, etc.
Having spatial support would make pgrust viable for a large class of location-aware applications without requiring a separate spatial database.
2. Search / pg_search
pg_search provides modern full-text search capabilities, including BM25-based ranking and inverted indexes, directly inside PostgreSQL.
This would provide a strong search primitive for applications that need:
- BM25 relevance
- full-text search
- fuzzy / relevance-oriented search
- fast search over large tables
- faceted/search-oriented queries
- hybrid lexical + vector search
pg_search is particularly interesting here because it is itself implemented as a Rust PostgreSQL extension, so it could potentially be an especially good candidate for exploring extension compatibility in pgrust.
3. Vector / pgvector
pgvector has become an important part of the PostgreSQL ecosystem for AI/ML applications.
It would be useful to support:
vector(n) data types
- vector operators
- cosine distance
- L2 distance
- inner product
- HNSW indexes
- IVFFlat indexes
- approximate nearest-neighbor search
- exact nearest-neighbor search
This would allow pgrust to support modern RAG, semantic search, recommendation, and AI workloads without requiring a separate vector database.
Feature: Spatial, full-text search, and vector support
First of all, great work on
pgrust. Getting a Rust rewrite of PostgreSQL to the point where it passes the PostgreSQL regression and isolation tests is extremely impressive.One area that I think would make
pgrustsubstantially more useful for real-world applications is support for some of the most important PostgreSQL extensions, particularly:pg_search(ParadeDB / BM25)pgvectorWhy these three?
Together, these extensions cover three increasingly common workloads that applications currently depend on PostgreSQL for:
1. Spatial / PostGIS
PostGIS provides PostgreSQL with spatial data types, spatial functions, and spatial indexing.
This is particularly important for applications requiring:
geometry/geographyST_DWithin,ST_Distance,ST_Contains,ST_Intersects, etc.Having spatial support would make
pgrustviable for a large class of location-aware applications without requiring a separate spatial database.2. Search /
pg_searchpg_searchprovides modern full-text search capabilities, including BM25-based ranking and inverted indexes, directly inside PostgreSQL.This would provide a strong search primitive for applications that need:
pg_searchis particularly interesting here because it is itself implemented as a Rust PostgreSQL extension, so it could potentially be an especially good candidate for exploring extension compatibility inpgrust.3. Vector /
pgvectorpgvectorhas become an important part of the PostgreSQL ecosystem for AI/ML applications.It would be useful to support:
vector(n)data typesThis would allow
pgrustto support modern RAG, semantic search, recommendation, and AI workloads without requiring a separate vector database.