Weaviate does not support a disk-resident ANN index. For more information, see Weaviate Limits.
Choosing Between OpenSearch, Weaviate, and pgvector
Last verified 13 Jul 2026
DigitalOcean Vector Databases are managed clusters purpose-built for vector similarity search, supporting Weaviate, OpenSearch, and PostgreSQL (pgvector) for retrieval-augmented generation (RAG), semantic search, and other AI workloads.
DigitalOcean Vector Databases support multiple engines so you can choose the architecture that best fits your application. Each engine can store and search vectors, but they are optimized for different workloads.
Choose an engine based on where your data already lives, how much you need full-text search, whether you want built-in vectorization, and how much operational complexity you want to manage:
| Engine | Best for | Choose it when | Operational fit |
|---|---|---|---|
| OpenSearch | Search-heavy applications | Search is a primary feature and you need hybrid search, full-text search, filtering, aggregations, or mature search controls. | Scales horizontally across nodes and uses REST APIs with low-level clients across many languages. |
| PostgreSQL with pgvector | Relational applications with vectors | Your application data already lives in PostgreSQL and vectors are part of that existing relational data model. | Scales vertically on a primary node, supports read-only nodes for read scaling, and works with standard PostgreSQL drivers and SQL. |
| Weaviate | Semantic search and RAG | You want the shortest path from documents to vector search with a vector-first database and built-in vectorization. | Scales horizontally across nodes and provides schema-aware Python and TypeScript clients. |
All three engines support automated daily backups with point-in-time recovery. Restoring from a backup creates a new cluster.
Choose an OpenSearch Vector Database
OpenSearch is the best choice when your application needs keyword search and vector search to work together. It’s a strong fit for workloads that need keyword matching, phrase queries, filters, and semantic relevance, such as:
- Product search
- Documentation search
- Ecommerce search
- Support search
- Log search
OpenSearch combines full-text search, vector search, filtering, aggregations, and search pipelines in one engine. This makes it useful when search quality depends on more than vector similarity alone.
OpenSearch doesn’t include built-in vectorization. Your application creates embeddings before writing data to the database and before running vector queries. You can use DigitalOcean Serverless Inference, a third-party provider, or a self-hosted model.
OpenSearch is more complex than a purpose-built vector database because it has more settings to understand and tune. For pure semantic search or simple RAG applications, OpenSearch may be more than you need. For those use cases, choose Weaviate instead.
Choose a PostgreSQL Vector Database
PostgreSQL with pgvector is the best choice when your vectors belong to data that already lives in PostgreSQL. It’s a strong fit for workloads that need vector search alongside relational data, such as:
- Application search over existing PostgreSQL records
- Customer or account-scoped search
- Permission-aware document search
- Recommendation features based on relational data
- RAG applications backed by existing PostgreSQL data
Use PostgreSQL with pgvector to store embeddings beside your relational data and query them with SQL. This is useful when vector search needs to respect relational filters, such as account ID, project ID, permissions, timestamps, or object type.
Because PostgreSQL doesn’t include built-in vectorization, your application creates embeddings before storing or querying vectors. You can use DigitalOcean Serverless Inference, a third-party provider, or a self-hosted model.
This option is simpler to operate when PostgreSQL is already your source of truth because you can use one database, one backup workflow, one set of credentials, and standard PostgreSQL drivers.
However, PostgreSQL isn’t built strictly for vector workloads. Very large or search-heavy vector workloads may require more tuning or may perform better on a dedicated vector or search engine. For those workloads, choose Weaviate or OpenSearch instead.
PostgreSQL also doesn’t provide native hybrid-search fusion. If hybrid search is a primary requirement, choose OpenSearch. You can combine PostgreSQL full-text search with vector search, but the ranking and fusion logic usually happens in application code.
Choose a Weaviate Vector Database private
Weaviate is the best choice when your application is primarily focused on semantic search, vector search, or retrieval-augmented generation (RAG). It’s a strong fit for workloads that need a vector-first data model and built-in vectorization, such as:
- Semantic document search
- RAG applications
- Recommendation systems
- Similarity search
- AI-powered content discovery
Weaviate is built for vector workloads and uses an opinionated data model based on collections, properties, and schemas. It also includes built-in vectorization through OpenAI, Cohere, Hugging Face, and other modules, which can simplify the path from raw text to searchable vectors.
Because Weaviate is optimized for vector-first workloads, it may be less suitable when your application depends on complex analytics, advanced full-text search, relational queries, joins, or SQL-based workflows. For those use cases, choose OpenSearch or PostgreSQL instead.
Choose to Migrate
Changing vector engines can be costly if your vector database is the only place where your embeddings exist. To make future migrations easier, treat the vector database as a derived index instead of the source of truth.
Store raw documents, metadata, and embeddings separately, such as in object storage or a relational table. If you later change engines, you can rebuild the vector index from that source without re-embedding all of your data.
You can also keep search logic behind a small application interface, such as search(query_text, filters, k). This makes it easier to replace one engine’s query implementation without rewriting the rest of your application.