diff --git a/docs-website/docs/concepts/document-store/choosing-a-document-store.mdx b/docs-website/docs/concepts/document-store/choosing-a-document-store.mdx index c0c544dae2..7bcc77c07d 100644 --- a/docs-website/docs/concepts/document-store/choosing-a-document-store.mdx +++ b/docs-website/docs/concepts/document-store/choosing-a-document-store.mdx @@ -9,103 +9,173 @@ import ClickableImage from "@site/src/components/ClickableImage"; # Choosing a Document Store -This article goes through different types of Document Stores and explains their advantages and disadvantages. +Whether you are developing a chatbot, a RAG system, or an image captioner, at some point, it's likely for your AI +application to compare the input it gets with the information it already knows. + +Haystack currently has integrations with seven categories of Document Stores: + +- **Vector Databases** — purpose-built for embedding search and semantic retrieval +- **Search Engines** — full-text search engines extended with vector (kNN) capabilities +- **Relational Databases** — SQL databases with vector search via plugins or extensions +- **Document / NoSQL Databases** — flexible document stores with vector search added on top +- **In-memory Key-Value Stores** — ultra-low-latency stores with HNSW vector search +- **Vector Index Libraries** — lightweight in-process vector similarity search, no external service +- **Multi-model Databases** — single engine supporting graph, document, and vector data models + +Here is an overview of all the integrations currently available, grouped by category: + + + +## DocumentStore Integrations Available in Haystack + +Haystack integrations come in two tiers. **Core integrations** are built and maintained by the Haystack team — they are tested against every release, follow the same API conventions, and come with full documentation and support. **External integrations** are contributed and maintained by the community; they extend Haystack's reach but are not covered by the core release cycle. + +The tables below list every available integration alongside the key properties you need to choose the right one for your use case: the underlying **Engine Type** gives you a sense of what the database is optimised for; **Open Source** tells you whether you can self-host it; **Async Support** matters for high-throughput pipelines; and **Retrievers** shows which retrieval strategies are available out of the box — BM25 for keyword search, Embedding for semantic search, Hybrid for both, and specialised options such as Sparse Embedding or SQL where supported. + +#### Core integrations + +| Integration | Category | Engine Type | Open Source | Async Support | Retrievers | +| --- | --- | --- | --- | --- | --- | +| ArcadeDB | Multi-model Database | Multi-model database (graph, document, key-value) with HNSW vector search via HTTP/JSON API | Yes | No | Embedding | +| AlloyDB | Relational Database | Managed PostgreSQL-compatible database (Google Cloud) with pgvector extension | No | Yes | Embedding, Keyword | +| Astra | Document / NoSQL Database | Cloud-native managed NoSQL (Apache Cassandra-based) with vector search via DataStax JSON API | No | No | Embedding | +| Azure AI Search | Search Engine | Managed cloud search service (Microsoft Azure AI Search) with HNSW vector search | No | No | BM25, Embedding, Hybrid | +| Chroma | Vector Database | Purpose-built vector database | Yes | Yes | Embedding | +| Elasticsearch | Search Engine | Distributed search & analytics engine with BM25 + vector (kNN) search | Partial | Yes | BM25, Embedding, SQL | +| FAISS | Vector Index Library | In-memory vector similarity search library (Meta/Facebook) with JSON file for metadata | Yes | No | Embedding | +| FalkorDB | Graph Database | OpenCypher graph database with ANN vector search | Yes (SSPL) | No | Embedding, Cypher | +| MongoDB Atlas | Document / NoSQL Database | Cloud document database with Atlas Vector Search and full-text search | No | Yes | Embedding, Full-text | +| Oracle | Relational Database | Oracle with native AI Vector Search, HNSW vector index and DBMS_SEARCH full-text keyword index | No | Yes | Embedding, Keyword | +| OpenSearch | Search Engine | Distributed search engine (AWS fork of Elasticsearch) with BM25 + kNN vector search | Yes | Yes | BM25, Embedding, Hybrid, Metadata, SQL | +| PGVector | Relational Database | Relational database (PostgreSQL) with the `pgvector` extension for vector similarity search | Yes | Yes | Embedding, Keyword | +| Pinecone | Vector Database | Managed cloud vector database | No | Yes | Embedding | +| Qdrant | Vector Database | Purpose-built vector database with dense + sparse embedding support | Yes | Yes | Embedding, Sparse Embedding, Hybrid | +| Supabase | Relational Database | Managed cloud Supabase — a wrapper over PgvectorDocumentStore with Supabase-specific defaults | Yes | Yes | Embedding, Keyword | +| Valkey | In-memory Key-Value Store | In-memory key-value store (Redis fork) with HNSW vector search via `glide` client | Yes | Yes | Embedding | +| Vespa | Search Engine | Distributed search & serving engine with BM25 lexical + HNSW vector (ANN) search | Yes | No | BM25, Embedding | +| Weaviate | Vector Database | Purpose-built vector database with hybrid search support | Yes | Yes | BM25, Embedding, Hybrid | + +#### External integrations + +| Integration | Category | Engine Type | Open Source | Async Support | Retrievers | +| --- | --- | --- | --- | --- | --- | +| Couchbase | Document / NoSQL Database | Distributed NoSQL document database with vector search via Search Service | Partial | Yes | Embedding, Full-text | +| LanceDB | Vector Database | Embedded vector database built on the Lance columnar format, optimized for multimodal data | Yes | Yes | Embedding, Full-text, Hybrid | +| Milvus | Vector Database | Open-source vector database built for scalable similarity search | Yes | No | Embedding | +| Needle | Search Engine | Managed RAG-as-a-service platform with built-in document storage and vector search | No | Yes | Embedding, Sparse Embedding, Hybrid | +| Neo4j | Multi-model Database | Graph database with native vector index support for combined graph traversal and similarity search | Partial | No | Embedding | +| SingleStore | Relational Database | Distributed SQL database with native vector search and full-text search support | No | Yes | Embedding, Full-text, Keyword | + +## Vector Databases + +- Purpose-built for vector and embedding search +- Advanced indexing techniques for efficient similarity search +- Designed for high scalability and availability with large volumes of high-dimensional data +- Most support metadata filtering alongside vector search +- Increasingly adding hybrid (vector + keyword) search support +- Mostly open source, widely available as managed cloud services + +**Best for** semantic search over large document corpora — e.g. a knowledge base where users search by meaning rather than exact keywords. -### Introduction - -Whether you are developing a chatbot, a RAG system, or an image captioner, at some point, it’ll be likely for your AI application to compare the input it gets with the information it already knows. Most of the time, this comparison is performed through vector similarity search. - -If you’re unfamiliar with vectors, think about them as a way to represent text, images, or audio/video in a numerical form called vector embeddings. Vector databases are specifically designed to store such vectors efficiently, providing all the functionalities an AI application needs to implement data retrieval and similarity search. - -Document Stores are special objects in Haystack that abstract all the different vector databases into a common interface that can be easily integrated into a pipeline, most commonly through a Retriever component. Normally, you will find specialized Document Store and Retriever objects for each vector database Haystack supports. - -### Types of vector databases - -But why are vector databases so different, and which one should you use in your Haystack pipeline? - -We can group vector databases into five categories, from more specialized to general purpose: - -- Vector libraries -- Pure vector databases -- Vector-capable SQL databases -- Vector-capable NoSQL databases -- Full-text search databases +- [Chroma](../../document-stores/chromadocumentstore.mdx) +- [Pinecone](../../document-stores/pinecone-document-store.mdx) +- [Qdrant](../../document-stores/qdrant-document-store.mdx) +- [Weaviate](../../document-stores/weaviatedocumentstore.mdx) +- [LanceDB](https://haystack.deepset.ai/integrations/lancedb) (external integration) +- [Milvus](https://haystack.deepset.ai/integrations/milvus-document-store) (external integration) -We are working on supporting all these types in Haystack. +## Search Engines -In the meantime, here’s the most recent overview of available integrations: - +- Originally built for full-text (BM25) search, with vector (kNN) capabilities added later +- Excellent support for text data, tokenisation, and language-aware querying +- Scale both horizontally and vertically in production environments +- Strong foundation for hybrid search combining keyword and semantic retrieval +- Battle-tested in enterprise environments with mature tooling and observability -#### Summary +**Best for** enterprise search or log analytics where both full-text (BM25) and vector search are needed — e.g. an e-commerce product search with filters. -Here is a quick summary of different Document Stores available in Haystack. +- Azure AI Search ([AzureAISearchDocumentStore](../../document-stores/azureaisearchdocumentstore.mdx)) +- [Elasticsearch](../../document-stores/elasticsearch-document-store.mdx) +- [OpenSearch](../../document-stores/opensearch-document-store.mdx) +- [Needle](https://haystack.deepset.ai/integrations/needle) (external integration) +- [Vespa](../../document-stores/vespadocumentstore.mdx) -Continue further down the article for a more complex explanation of the strengths and disadvantages of each type. +## Relational Databases -
+- Standard SQL databases extended with vector search via plugins or extensions +- Vectors live alongside relational data, enabling combined vector + SQL queries in a single store +- Lower operational overhead when PostgreSQL is already part of the stack +- Vector search performance is lower than purpose-built databases, but sufficient for many use cases +- Familiar tooling, transactions, and data integrity guarantees of a relational database -| | | -| --- | --- | -| Type | Best for | -| Vector libraries | Managing hardware resources effectively. | -| Pure vector DBs | Managing lots of high-dimensional data. | -| Vector-capable SQL DBs | Lower maintenance costs with focus on structured data and less on vectors. | -| Vector-capable NoSQL DBs | Combining vectors with structured data without the limitations of the traditional relational model. | -| Full-text search DBs | Superior full-text search, reliable for production. | -| In-memory | Fast, minimal prototypes on small datasets. | +**Best for** use cases where documents live alongside structured relational data — e.g. a product catalogue where vector search and SQL JOINs are both needed. -
+- [AlloyDB](../../document-stores/alloydbdocumentstore.mdx) +- [Oracle](../../document-stores/oracledocumentstore.mdx) +- [PGVector](../../document-stores/pgvectordocumentstore.mdx) +- [Supabase](../../document-stores/supabasedocumentstore.mdx) +- [SingleStore](https://haystack.deepset.ai/integrations/singlestore) (external integration) -#### Vector libraries +## Document / NoSQL Databases -Vector libraries are often included in the “vector database” category improperly, as they are limited to handling only vectors, are designed to work in-memory, and normally don’t have a clean way to store data on disk. Still, they are the way to go every time performance and speed are the top requirements for your AI application, as these libraries can use hardware resources very effectively. +- General-purpose document stores with vector search added on top +- Flexible, schema-less data model suited for heterogeneous document collections +- Horizontal scaling and high availability inherited from the underlying NoSQL engine +- Good choice when the database is already in use and adding a separate vector store is undesirable +- Vector search performance may trail behind purpose-built databases -:::warning[In progress] +**Best for** applications already using MongoDB or Cassandra that want to add RAG capabilities without introducing a new infrastructure component. -We are currently developing the support for vector libraries in Haystack. -::: +- Astra ([AstraDocumentStore](../../document-stores/astradocumentstore.mdx)) +- [MongoDB Atlas](../../document-stores/mongodbatlasdocumentstore.mdx) +- [Couchbase](https://haystack.deepset.ai/integrations/couchbase-document-store) (external integration) -#### Pure vector databases +## In-memory Key-Value Stores -Pure vector databases, also known as just “vector databases”, offer efficient similarity search capabilities through advanced indexing techniques. Most of them support metadata, and despite a recent trend to add more text-search features on top of it, you should consider pure vector databases closer to vector libraries than a regular database. Pick a pure vector database when your application needs to manage huge amounts of high-dimensional data effectively: they are designed to be highly scalable and highly available. Most are open source, but companies usually provide them “as a service” through paid subscriptions. +- In-memory architecture delivers extremely low read/write latency +- Vector search (HNSW) layered on top of an existing caching infrastructure +- Ideal when the stack already includes Redis or Valkey as a cache or session store +- Data is ephemeral by default; persistence requires explicit configuration +- Less suited for large corpora where memory cost becomes significant -- [Chroma](../../document-stores/chromadocumentstore.mdx) -- [Pinecone](../../document-stores/pinecone-document-store.mdx) -- [Qdrant](../../document-stores/qdrant-document-store.mdx) -- [Weaviate](../../document-stores/weaviatedocumentstore.mdx) -- [Milvus](https://haystack.deepset.ai/integrations/milvus-document-store) (external integration) +**Best for** low-latency, real-time retrieval — e.g. a chatbot that needs sub-millisecond response times. -#### Vector-capable SQL databases +- [Valkey](../../document-stores/valkeydocumentstore.mdx) -This category is relatively small but growing fast and includes well-known relational databases where vector capabilities were added through plugins or extensions. They are not as performant as the previous categories, but the main advantage of these databases is the opportunity to easily combine vectors with structured data, having a one-stop data shop for your application. You should pick a vector-capable SQL database when the performance trade-off is paid off by the lower cost of maintaining a single database instance for your application or when the structured data plays a more fundamental role in your business logic, with vectors being more of a nice-to-have. +## Vector Index Libraries -- [Oracle](../../document-stores/oracledocumentstore.mdx) -- [Pgvector](../../document-stores/pgvectordocumentstore.mdx) -- [Supabase](../../document-stores/supabasedocumentstore.mdx) +- Low-level, in-process vector similarity search — not a full database +- No network overhead; runs entirely within the application process +- Very efficient use of hardware resources (CPU/GPU) +- Limited to vectors only; metadata must be managed separately (e.g. via a JSON file) +- No built-in persistence, replication, or multi-client access -#### Vector-capable NoSQL databases +**Best for** local prototyping, research, or small-scale applications where a lightweight in-process solution is preferred over running an external database server. -Historically, the killer features of NoSQL databases were the ability to scale horizontally and the adoption of a flexible data model to overcome certain limitations of the traditional relational model. This stays true for databases in this category, where the vector capabilities are added on top of the existing features. Similarly to the previous category, vector support might not be as good as pure vector databases, but once again, there is a tradeoff that might be convenient to bear depending on the use case. For example, if a certain NoSQL database is already part of the stack of your application and a lower performance is not a show-stopper, you might give it a shot. +- [FAISS](../../document-stores/faissdocumentstore.mdx) -- [Astra](../../document-stores/astradocumentstore.mdx) -- [MongoDB](../../document-stores/mongodbatlasdocumentstore.mdx) -- [Neo4j](https://haystack.deepset.ai/integrations/neo4j-document-store) (external) +## Multi-model Databases -#### Full-text search databases +- Single engine supporting multiple data models: graph, document, key-value, and vector +- Eliminates the need to maintain separate databases for different data representations +- Suited for knowledge graphs or applications with complex entity relationships +- Vector search (HNSW) available alongside graph traversal and document queries +- Smaller community and ecosystem compared to more established categories -The main advantage of full-text search databases is they are already designed to work with text, so you can expect a high level of support for text data along with good performance and the opportunity to scale both horizontally and vertically. Initially, vector capabilities were subpar and provided through plugins or extensions, but this is rapidly changing. You can see how the market leaders in this category have recently added first-class support for vectors. Pick a full-text search database if text data plays a central role in your business logic so that you can easily and effectively implement techniques like hybrid search with a good level of support for similarity search and state-of-the-art support for full-text search. +**Best for** applications requiring multiple data models in a single engine — e.g. a knowledge graph where entities are connected by relationships and also need vector similarity search. -- [Elasticsearch](../../document-stores/elasticsearch-document-store.mdx) -- [OpenSearch](../../document-stores/opensearch-document-store.mdx) +- [ArcadeDB](../../document-stores/arcadedbdocumentstore.mdx) +- [FalkorDB](../../document-stores/falkordbdocumentstore.mdx) +- [Neo4j](https://haystack.deepset.ai/integrations/neo4j-document-store) (external integration) -#### The in-memory Document Store +## The In-memory Document Store -Haystack ships with an ephemeral document store that relies on pure Python data structures stored in memory, so it doesn’t fall into any of the vector database categories above. This special Document Store is ideal for creating quick prototypes with small datasets. It doesn’t require any special setup, and it can be used right away without installing additional dependencies. +Haystack ships with an ephemeral document store that relies on pure Python data structures stored in memory, so it doesn't fall into any of the vector database categories above. This special Document Store is ideal for creating quick prototypes with small datasets. It doesn't require any special setup, and it can be used right away without installing additional dependencies. -- [InMemory](../../document-stores/inmemorydocumentstore.mdx) +- [InMemoryDocumentStore](../../document-stores/inmemorydocumentstore.mdx) -### Final considerations +## Final Considerations It can be very challenging to pick one vector database over another by only looking at pure performance, as even the slightest difference in the benchmark can produce a different leaderboard (for example, some benchmarks test the cloud services while others work on a reference machine). Thinking about including features like filtering or not can bring in a whole new set of complexities that make the comparison even harder. -What’s important for you to know is that the Document Store interface doesn’t add much to the costs, and the relative performance of one vector database over another should stay the same when used within Haystack pipelines. +What's important for you to know is that the Document Store interface doesn't add much to the costs, and the relative performance of one vector database over another should stay the same when used within Haystack pipelines. diff --git a/docs-website/src/css/custom.css b/docs-website/src/css/custom.css index 6570bd63ff..63f723ddcd 100644 --- a/docs-website/src/css/custom.css +++ b/docs-website/src/css/custom.css @@ -996,3 +996,11 @@ html[data-theme='dark'] .navbar-version-badge-dropdown:hover > a::after { display: none !important; } } + +/* Inline logos next to integration names */ +.ds-logo { + height: 14px; + vertical-align: middle; + margin-right: 5px; + display: inline; +} diff --git a/docs-website/static/img/document-stores-overview.svg b/docs-website/static/img/document-stores-overview.svg new file mode 100644 index 0000000000..ea984b95f8 --- /dev/null +++ b/docs-website/static/img/document-stores-overview.svg @@ -0,0 +1,64 @@ + + + + + +Vector Databases + + + + + + + + + +Search Engines + +Azure +AI Search + + + +Needle +* + + + + +Relational Databases + + + + +Supabase + + + + +Document / NoSQL + +Astra + + + + + +In-memory Key-Value + + + + +Vector Index Libraries + +FAISS + + + +Multi-model Databases + +ArcadeDB + + +* External (community-maintained) integration + diff --git a/docs-website/static/img/logos/document-stores/alloydb.svg b/docs-website/static/img/logos/document-stores/alloydb.svg new file mode 100644 index 0000000000..ecb11c6067 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/alloydb.svg @@ -0,0 +1,104 @@ + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/arcadedb.png b/docs-website/static/img/logos/document-stores/arcadedb.png new file mode 100644 index 0000000000..4fe49c8591 Binary files /dev/null and b/docs-website/static/img/logos/document-stores/arcadedb.png differ diff --git a/docs-website/static/img/logos/document-stores/astra.png b/docs-website/static/img/logos/document-stores/astra.png new file mode 100644 index 0000000000..d445fe318b Binary files /dev/null and b/docs-website/static/img/logos/document-stores/astra.png differ diff --git a/docs-website/static/img/logos/document-stores/azure.svg b/docs-website/static/img/logos/document-stores/azure.svg new file mode 100644 index 0000000000..46f235d396 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/azure.svg @@ -0,0 +1 @@ +Icon-web-44 diff --git a/docs-website/static/img/logos/document-stores/chroma.svg b/docs-website/static/img/logos/document-stores/chroma.svg new file mode 100644 index 0000000000..473026c206 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/chroma.svg @@ -0,0 +1,83 @@ + + + + + + + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/couchbase.svg b/docs-website/static/img/logos/document-stores/couchbase.svg new file mode 100644 index 0000000000..44fe6f1b63 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/couchbase.svg @@ -0,0 +1 @@ +logo diff --git a/docs-website/static/img/logos/document-stores/elasticsearch.svg b/docs-website/static/img/logos/document-stores/elasticsearch.svg new file mode 100644 index 0000000000..fffaffaa93 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/elasticsearch.svg @@ -0,0 +1,3 @@ + + + diff --git a/docs-website/static/img/logos/document-stores/faiss.png b/docs-website/static/img/logos/document-stores/faiss.png new file mode 100644 index 0000000000..b95daefa25 Binary files /dev/null and b/docs-website/static/img/logos/document-stores/faiss.png differ diff --git a/docs-website/static/img/logos/document-stores/falkordb.svg b/docs-website/static/img/logos/document-stores/falkordb.svg new file mode 100644 index 0000000000..81a10cfe20 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/falkordb.svg @@ -0,0 +1 @@ + diff --git a/docs-website/static/img/logos/document-stores/lancedb.svg b/docs-website/static/img/logos/document-stores/lancedb.svg new file mode 100644 index 0000000000..f44bf3b187 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/lancedb.svg @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/milvus.svg b/docs-website/static/img/logos/document-stores/milvus.svg new file mode 100644 index 0000000000..4c2e866cb1 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/milvus.svg @@ -0,0 +1,11 @@ + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/mongodb.svg b/docs-website/static/img/logos/document-stores/mongodb.svg new file mode 100644 index 0000000000..57321296bf --- /dev/null +++ b/docs-website/static/img/logos/document-stores/mongodb.svg @@ -0,0 +1,11 @@ + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/needle.png b/docs-website/static/img/logos/document-stores/needle.png new file mode 100644 index 0000000000..5f88be0793 Binary files /dev/null and b/docs-website/static/img/logos/document-stores/needle.png differ diff --git a/docs-website/static/img/logos/document-stores/neo4j.svg b/docs-website/static/img/logos/document-stores/neo4j.svg new file mode 100644 index 0000000000..85e167624c --- /dev/null +++ b/docs-website/static/img/logos/document-stores/neo4j.svg @@ -0,0 +1,29 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/opensearch.svg b/docs-website/static/img/logos/document-stores/opensearch.svg new file mode 100644 index 0000000000..a59dc45372 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/opensearch.svg @@ -0,0 +1,7 @@ + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/oracle.svg b/docs-website/static/img/logos/document-stores/oracle.svg new file mode 100644 index 0000000000..bad99882dd --- /dev/null +++ b/docs-website/static/img/logos/document-stores/oracle.svg @@ -0,0 +1 @@ + diff --git a/docs-website/static/img/logos/document-stores/pinecone.svg b/docs-website/static/img/logos/document-stores/pinecone.svg new file mode 100644 index 0000000000..e051115721 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/pinecone.svg @@ -0,0 +1 @@ + diff --git a/docs-website/static/img/logos/document-stores/postgresql.svg b/docs-website/static/img/logos/document-stores/postgresql.svg new file mode 100644 index 0000000000..c9ecc078fd --- /dev/null +++ b/docs-website/static/img/logos/document-stores/postgresql.svg @@ -0,0 +1,250 @@ + + + +image/svg+xml diff --git a/docs-website/static/img/logos/document-stores/qdrant.svg b/docs-website/static/img/logos/document-stores/qdrant.svg new file mode 100644 index 0000000000..82fb8b3938 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/qdrant.svg @@ -0,0 +1,27 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/singlestore.svg b/docs-website/static/img/logos/document-stores/singlestore.svg new file mode 100644 index 0000000000..64504f7e4c --- /dev/null +++ b/docs-website/static/img/logos/document-stores/singlestore.svg @@ -0,0 +1,221 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/supabase.svg b/docs-website/static/img/logos/document-stores/supabase.svg new file mode 100644 index 0000000000..574f67eca7 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/supabase.svg @@ -0,0 +1,15 @@ + + + + + + + + + + + + + + + diff --git a/docs-website/static/img/logos/document-stores/valkey.svg b/docs-website/static/img/logos/document-stores/valkey.svg new file mode 100644 index 0000000000..1581bbd4fa --- /dev/null +++ b/docs-website/static/img/logos/document-stores/valkey.svg @@ -0,0 +1 @@ + diff --git a/docs-website/static/img/logos/document-stores/vespa.svg b/docs-website/static/img/logos/document-stores/vespa.svg new file mode 100644 index 0000000000..e9285326e7 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/vespa.svg @@ -0,0 +1 @@ +VespaLogo copy diff --git a/docs-website/static/img/logos/document-stores/weaviate.svg b/docs-website/static/img/logos/document-stores/weaviate.svg new file mode 100644 index 0000000000..e432c21c61 --- /dev/null +++ b/docs-website/static/img/logos/document-stores/weaviate.svg @@ -0,0 +1,504 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/pyproject.toml b/pyproject.toml index 43bd669416..afbab59cd8 100644 --- a/pyproject.toml +++ b/pyproject.toml @@ -199,7 +199,7 @@ packages = ["haystack"] [tool.codespell] ignore-words-list = "ans,astroid,nd,ned,nin,ue,rouge,ist, Claus,SME" quiet-level = 3 -skip = "./test,./e2e" +skip = "./test,./e2e,*.svg" [tool.pytest.ini_options] minversion = "6.0"