Since switching to users to Pinecone Serverless, many users have complained about data freshness. They have reported that new or changed records are not immediately visible to queries. This is a common issue with systems that use eventual consistency.

To quote Pinecone's documentation: "Pinecone is eventually consistent, so there can be a slight delay before new or changed records are visible to queries"

This delay can be a problem for applications that require real-time data updates. For example, if you are building a recommendation system that needs to update user preferences in real-time, eventual consistency can lead to stale recommendations. Or if a user updates their profile, they might not see the changes reflected in search results immediately, leading to a poor user experience.

What can you do?​

Due to the nature of how Pinecone works, this is a fundamental design choice and cannot be fixed by end users.

If you're building a real-time application that requires immediate data updates, you might want to consider other options that offer stronger consistency guarantees.

SvectorDB is a serverless pay-as-you-go vector database that offers immediate consistency guarantees. It is designed to provide real-time updates and is ideal for applications that require immediate data visibility. With SvectorDB, you can be confident that your data is always up-to-date and consistent across all queries.

Choosing the right vector database is crucial for efficiently managing and querying large datasets in modern applications. AWS offers a range of robust options, each tailored to different use cases, performance requirements, and budget considerations. This article explores the top five vector database options available on AWS: Amazon OpenSearch, Amazon RDS, Amazon MemoryDB, Amazon DocumentDB, and the one AWS should have built: SvectorDB. By examining their features, deployment models, and cost structures, you'll be equipped to select the best solution to meet your specific needs.

1. Amazon OpenSearch​

Amazon OpenSearch is a robust, fully managed service designed to simplify the deployment, security, and operation of OpenSearch (formerly known as ElasticSearch) at scale. It is an excellent solution for a wide array of use cases, including log analytics, full-text search, and application monitoring. By leveraging Amazon OpenSearch, organizations can gain insights from their data in near real-time, enhancing their ability to respond to business needs swiftly.

Amazon OpenSearch offers high availability and durability with its automated snapshots and backups. The service integrates seamlessly with other AWS offerings, providing a comprehensive ecosystem for data management and analytics. Users benefit from powerful search capabilities and analytics tools that help extract meaningful information from vast datasets.

AWS provides two deployment options with different pricing structures:

2. Amazon RDS​

Amazon RDS (Relational Database Service) is a versatile, fully managed database service that supports multiple database engines, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server. This flexibility allows organizations to choose the best database for their specific application needs. Aurora for PostgreSQL supports vector search, which is crucial for modern applications requiring advanced search capabilities.

Amazon RDS automates many time-consuming administrative tasks such as hardware provisioning, database setup, patching, and backups. This automation allows database administrators to focus on higher-value tasks rather than routine maintenance. The service also provides high availability and durability through Multi-AZ deployments and read replicas, ensuring that your data is safe and accessible when you need it.

Consistency is dependent on whether you have replicas configured or not.

3. Amazon MemoryDB​

Amazon MemoryDB for Redis is a Redis-compatible, in-memory database service that delivers ultra-fast performance with microsecond latency. It is designed for use cases requiring real-time data processing, such as caching, session management, real-time analytics, and gaming leaderboards. By storing data in memory, Amazon MemoryDB enables applications to access information at lightning speed, providing a seamless user experience.

MemoryDB is fully managed, which means AWS handles the administrative tasks, including setup, configuration, scaling, and patching. The service also offers high availability and automatic failover, ensuring that your applications remain up and running even in the event of hardware failures. With its compatibility with Redis, you can leverage existing Redis tools and libraries, making it easy to migrate your applications to MemoryDB.

4. Amazon DocumentDB​

Amazon DocumentDB (with MongoDB compatibility) is a fast, scalable, and highly available document database service designed to support JSON workloads. It is fully managed, providing automated backup, patching, and scaling, which frees up developers to focus on building applications rather than managing databases.

DocumentDB is built to be highly compatible with MongoDB, allowing users to use the same MongoDB drivers, tools, and applications without modification. This makes it an attractive option for organizations looking to migrate from MongoDB to a managed service on AWS. DocumentDB's architecture separates compute and storage, which allows it to scale elastically and provide high performance for your applications.

5. The missing one: SvectorDB​

SvectorDB is the serverless vector database that AWS should have built. True serverless services should be managed, automatically scale (including down to zero), and charge based on actual usage, not provisioned capacity.

That's why SvectorDB was created: a serverless vector database for serverless workloads on AWS, operating on a pay-per-request model with native CloudFormation support. The API is simple, focusing on core functionalities: insert, update, search, and delete. Built with Smithy, the SDK feels familiar to AWS SDK users, and it includes built-in vectorizers for easy indexing and searching of vectors without hosting your own models.

SvectorDB is perfect for those seeking a truly serverless solution with flexible, usage-based pricing.

Conclusion​

When selecting a vector database for AWS workloads, consider your specific use case, budget, and desired level of control. Amazon OpenSearch, Amazon RDS, Amazon MemoryDB, and Amazon DocumentDB are all excellent choices. However, if you need a truly serverless solution with usage-based pricing, SvectorDB is worth exploring.

Having a hard time figuring out how much Pinecone's Serverless offering will cost you? So are we! Pinecone's pricing is opaque and hard to understand. This calculator is an attempt to make it easier

In comparison, SvectorDB's pricing is simple and transparent. You pay for the number of queries, writes, and storage you use. You can see the pricing here.

Price Comparison Calculator

Queries per month

1k10k100k1M10M100M1B1M

Writes per month

1k10k100k1M10M100M1B100k

Vector Dimension

32641282563845126407688961024384

Vectors Stored

25k50k100k250k500k750k1M500k

SvectorDB

$7.25/m

Pinecone

$83.44/m

SvectorDB calculations

Feature	Amount	Units	Cost	Total
Queries	1m	1 Read Operation	$5 / million	$5.00
Writes	100k	1 Write Operation	$20 / million	$2.00
Storage	500k vectors	~1.018 GB	$0.25 / GB	$0.25
				$7.25

Pinecone calculations

Feature	Amount	Units	Cost	Total
Queries*	1m	10 Read Units	$8.25 / million	$82.50
Writes	100k	3 Write Units	$2.00 / million	$0.60
Storage	500k vectors	~1.018 GB	$0.33 / GB	$0.34
				$83.44

* Fetching 32 nearest neighbours and returning metadata

No, DynamoDB is a key-value store and does not support vector search. However, by using SvectorDB, you can index your DynamoDB tables in real-time and perform vector searches on the indexed data. This integration leverages DynamoDB streams and a Lambda function to keep your vector index up-to-date automatically.

How to Set Up Real-Time Vector Indexing with DynamoDB and SvectorDB​

We’ve created a one-click deploy CloudFormation stack that makes it easy to set up real-time vector indexing for your DynamoDB tables using SvectorDB. Follow the steps below to deploy the stack and start indexing your data.

For the source code and CloudFormation template, visit the DynamoDB Indexer GitHub repository.

Step-by-Step Guide​

1. Download and Prepare the Lambda Code

   Download the latest compiled code from the releases page or compile the source code yourself with the following commands:

   cd code
   npm install
   npm run build
   

   Once compiled, upload the code to an S3 bucket in your AWS account.

2. Enable SvectorDB CloudFormation Extensions

   Ensure that the SvectorDB CloudFormation extensions are enabled in your account. You can do this by following the instructions in the SvectorDB documentation.

3. Enable DynamoDB Streams

   Make sure that your source DynamoDB table has DynamoDB streams enabled. This is necessary for the Lambda function to subscribe to changes in the table and update the index in real-time.

4. Deploy the CloudFormation Stack

   Use the provided CloudFormation template to deploy the stack. You'll need to provide the following parameters:

   • DynamoDbStreamArn: The ARN of the DynamoDB stream to subscribe to.
   • SvectorDbIntegrationId: The ID in your SvectorDB dashboard for the CloudFormation integration. Ensure your AWS account ID is added to the allowed accounts list.
   • VectorDimension: The dimension of the vector index.
   • VectorDistanceMetric: The distance metric to use for the index.
   • VectorFieldToIndex: The name of the field in the source table to use as the document's vector. This field must be a list of numbers.
   • DatabaseType: The tier of database to create (e.g., sandbox for the free tier).
   • LambdaBucket: The name of the S3 bucket where the Lambda code is stored.
   • LambdaKey: The key of the Lambda code in the S3 bucket.

   After deploying the stack, the index will be updated in real-time as records are added, updated, or deleted from the source table.

5. Perform Vector Searches

   Use the index to perform nearest neighbor searches. Check out the code/src/demo.ts file for an example of how to use the index for this purpose.

Additional Resources​

For more information on setting up and using the vector index, visit the SvectorDB Quick Start guide. This guide provides comprehensive instructions and examples to help you get the most out of your SvectorDB integration.

By following these steps, you can effectively use SvectorDB to index and search your DynamoDB tables in real-time, combining the scalability of DynamoDB with the powerful vector search capabilities of SvectorDB.

Vector databases are transforming how applications handle vector search, making them ideal for image and document retrieval, recommendation systems, and RAG models. With various options available, selecting the right vector search solution can be challenging.

This article explores three popular choices: pgvector, Pinecone, and SvectorDB. We'll examine their pros and cons to help you choose the best tool for your next project.

pgvector​

pgvector is an open-source extension that adds vector search capabilities to your existing PostgreSQL database. Here’s what makes it a compelling choice:

Pros​

• Open-source: Freely available with a large community supporting it.
• Integrates with existing databases: Enhances PostgreSQL, allowing easy integration with your current database setup.
• Vendor-neutral: Can be run on any cloud platform or on-premises, providing flexibility.

Cons​

• Requires database management: You need to set up and maintain your PostgreSQL database.
• Performance impact: Adding pgvector can affect the performance of other database operations.
• Server costs: You must cover the server expenses to run your PostgreSQL database continuously.

Pinecone​

Pinecone offers a managed vector database service, simplifying the development and deployment of vector search applications. Here’s what makes Pinecone stand out:

Pros​

• Hybrid search: Allows filtering results by both vector similarity and metadata within the same index.
• Serverless option: Pay only for reads, writes, and storage, with no need to manage servers.
• Market leader: Well-established in the vector search space.

Cons​

• Vendor lock-in: A proprietary service that locks you into their platform.
• Costs: More expensive than other options, including other managed services.

SvectorDB​

SvectorDB is a serverless vector database designed for production APIs, particularly those running on AWS environments. Here’s what sets it apart:

Pros​

• Native AWS integration: Designed for AWS with CloudFormation support and familiar SDKs for a seamless AWS experience.
• Serverless: Pay only for reads, writes, and storage, with no need to manage servers.
• Built-in vectorizers: Simplifies the workflow by providing pre-built vectorizers for common models.
• Cost-effective: Often 10x cheaper than Pinecone, making it a budget-friendly option.

Cons​

• No hybrid search: Can only search by vector similarity.
• Vendor lock-in: A proprietary service that ties you to their platform.

Making the Right Choice​

The best choice depends on your specific project needs. Here’s a quick guide to help you decide:

• Choose pgvector if: You want an open-source solution that integrates with your existing PostgreSQL database and are comfortable managing your own infrastructure.
• Choose Pinecone if: You need a hybrid search solution and are willing to pay a premium for a managed service.
• Choose SvectorDB if: You’re looking for a cost-effective serverless solution with native AWS integration and built-in vectorizers.

Price Comparison Calculator

Queries per month

1k10k100k1M10M100M1B1M

Writes per month

1k10k100k1M10M100M1B100k

Vector Dimension

32641282563845126407688961024384

Vectors Stored

25k50k100k250k500k750k1M500k

SvectorDB

$7.25/m

Pinecone

$83.44/m

SvectorDB calculations

Feature	Amount	Units	Cost	Total
Queries	1m	1 Read Operation	$5 / million	$5.00
Writes	100k	1 Write Operation	$20 / million	$2.00
Storage	500k vectors	~1.018 GB	$0.25 / GB	$0.25
				$7.25

Pinecone calculations

Feature	Amount	Units	Cost	Total
Queries*	1m	10 Read Units	$8.25 / million	$82.50
Writes	100k	3 Write Units	$2.00 / million	$0.60
Storage	500k vectors	~1.018 GB	$0.33 / GB	$0.34
				$83.44

* Fetching 32 nearest neighbours and returning metadata

Let's build a simple image search engine, which allows you to search for images using text. We'll use SvectorDB to create and query our embeddings.

Setup

Create a new folder and run the following commands:

npm init -y
npm install @svector/client

Next, let's create a new file called index.ts and add the following code:

import { DatabaseService, EmbeddingModel } from '@svector/client';

const region = 'us-east-2';
const apiKey = ''; // replace with your API key
const databaseId = ''; // replace with your database ID

const client = new DatabaseService({
    endpoint: `https://${region}.api.svectordb.com`,
    apiKey: apiKey,
});

Create a new database

Let's create a new database to store our image embeddings. You'll need to sign up for a free account at SvectorDB and create a database with 512 dimensions. Once you've created the database, copy the API key and database ID into the above code.

For help on creating a new database, check out the quick start guide.

Add images to the database

Next, let's add some images to the database. We'll use SvectorDB's built-in support for OpenAI's CLIP model to generate embeddings for the images. This model can generate embeddings for both text and images, allowing us to search for images using text.

const imagePath = `./image/apple-1.jpg`;
const imageBuffer = readFileSync(imagePath);

const { vector } = await client.embed({
    databaseId,
    model: EmbeddingModel.CLIP_VIT_BASE_PATH32,
    input: {
        image: imageBuffer,
    }
})

await client.setItem({
    databaseId,
    key: 'apple-1',
    value: Buffer.from(imagePath),
    vector: vector,
})

In the above code, we're loading an image from the file system and generating an embedding using the CLIP model. We then store the image embedding in the database with the key apple-1. Each item in the database should have a unique key, otherwise, it will be treated as an update. Repeat this for each image you want to add to the database.

Search for images

Embeddings locate similar items close together, e.g. the apples will be close together in space but far from bananas. We can use the distance between embeddings to find the nearest images to our query.

OpenAI's CLIP model can generate embeddings for both text and images, so we can search for images by finding the nearest embeddings to our text query. For example, if we search for "Green apples", the nearest images will be those of green apples.

const searchQuery = `Green apples`;

const { vector } = await client.embed({
    databaseId,
    model: EmbeddingModel.CLIP_VIT_BASE_PATH32,
    input: {
        text: searchQuery,
    },
});

const { results } = await client.query({
    databaseId,
    query: {
        vector: vector!,
    },
    maxResults: 5
})

With our nearest images found, we can now load them and pass them to the front-end with their scores:

const pictures = results!
    .map(({distance, value}) => ({
        score: distance,
        image: readFileSync(value!.toString())
    }));

The world of vector databases is booming, offering exciting possibilities for tasks like image and product search, recommendation systems, and natural language processing. But with so many options, a crucial question arises: if you're just starting out with a dataset under 1 million vectors, do you need a full-fledged vector database?

While traditional solutions like FAISS or database plugins might seem sufficient, they might not consider the long-term needs of managing and maintaining your vector data, especially as your project grows.

This is where serverless, pay-as-you-go vector databases like SvectorDB become attractive. They offer a powerful alternative, especially for those who prioritize:

• Real-Time Updates: Picture a scenario where user and item vectors dynamically change in a recommendation system. While managing real-time updates within a distributed embedded solution is possible, it quickly becomes complex and costly. SvectorDB, designed for live updates, streamlines this process

• Effortless Management: Setting up and maintaining a traditional database, even for smaller datasets, can be a time-consuming chore. Serverless options like SvectorDB handle the infrastructure headaches, allowing you to focus on what matters - building your application.

• Scalability Made Simple: Suppose your project gains traction, and your vector collection surpasses 1 million. With a serverless vector database, scaling happens automatically. Your database seamlessly grows alongside your needs, eliminating the need for expensive infrastructure upgrades and downtime

• Pay-Per-Use Efficiency: For smaller datasets, traditional databases often lead to underutilised resources. Serverless options like SvectorDB follow a pay-as-you-go model, ensuring you only pay for the storage and queries you actually use. This aligns perfectly with a business model where costs should scale with usage.

Think of it this way: While a basic screwdriver might tighten a screw, a power drill gets the job done faster and more efficiently. Similarly, a serverless vector database like SvectorDB offers the power and flexibility of a full-fledged solution, even for smaller datasets. It simplifies management, scales effortlessly, and aligns with a usage-based pricing model – all factors that free you to focus on innovation and growth.

So, the next time you're starting a vector-powered project, consider the bigger picture. Don't get bogged down by database management – choose a serverless solution that empowers you to build, iterate, and scale with ease.

Vector databases are revolutionizing applications that rely on similarity searches, like image and product recommendations, anomaly detection, and personalized search. But with a growing number of options, choosing the right vector database can be tricky. Two popular choices are pgvector and Pinecone. Let's delve into their strengths and weaknesses to help you make an informed decision.

* Each query and insert uses a variable amount of read / write units

** Each query and insert uses exactly 1 read / write operation

*** Querying a 384-dimensional index with 100k entries for 50 results

pgvector: The SQL-Friendly Option​

pgvector is an extension for PostgreSQL, a widely used relational database. This makes it a natural fit for existing PostgreSQL users who want to leverage vector search without a significant migration effort. Here's what makes pgvector attractive:

• SQL Integration: Seamlessly integrate vector search with your existing SQL queries for a unified data management experience.
• Open Source: Freely available and customizable, offering greater control over your data infrastructure.

However, there are some trade-offs:

• Scalability: While suitable for smaller datasets, pgvector can struggle with massive data volumes.
• Performance: May not deliver the fastest search speeds compared to dedicated vector databases.

Pinecone: The Cloud-Native Powerhouse​

Pinecone is a managed vector database service designed for high-performance and scalability. It offers several advantages:

• Cloud-Based: Effortless deployment and management, eliminating infrastructure headaches.
• Performance: Delivers blazing-fast search speeds even for large datasets.
• Ease of Use: User-friendly interface and pre-built libraries simplify integration.

However, Pinecone also has limitations:

• Cost: Can be more expensive compared to open-source options like pgvector, especially for high-volume workloads.
• Vendor Lock-In: Relies on Pinecone's infrastructure, limiting flexibility if you need to switch providers.

The SvectorDB Advantage

While this comparison focused on pgvector and Pinecone, there's another strong contender – SvectorDB. Here's how SvectorDB stacks up against the competition:

• Scalability: Handles large datasets efficiently, similar to Pinecone.
• Cost-Effectiveness: Offers a transparent pricing model with lower costs compared to Pinecone.
• Serverless: Ideal for serverless architectures, providing flexibility and cost savings.

Choosing Your Vector Database Solution

The best choice depends on your specific needs. Here's a quick guide:

• For existing PostgreSQL users with moderate data volumes and a preference for SQL integration, pgvector could be a good fit.
• For cloud-based deployments demanding high performance and scalability, Pinecone is a strong contender.
• For a cost-effective, flexible, and serverless-friendly option with excellent scalability, consider SvectorDB.

With the recent introduction of Pinecone's serverless option, it's worth exploring how it stacks up against SvectorDB. While both Pinecone and SvectorDB share commonalities, their distinctions emerge prominently in their pricing models and client support.

Pricing​

Pinecone adopts a pricing model that hinges on three primary dimensions: read units, write units, and storage. While storage costs are straightforward, understanding read and write units can be a bit intricate. Though the exact calculation method for these units remains unclear, Pinecone provides some examples for illustration.

In contrast, SvectorDB's pricing model is notably more transparent. It is based on the number of read requests, write requests, and the compressed size of the index.

Client support​

Pinecone has native Python and JavaScript libraries. SvectorDB goes a step further by providing an official OpenAPI specification, enabling the automatic generation of client libraries for any programming language. This flexibility ensures that even if your preferred language is not natively supported by SvectorDB, you won't have to create a custom client library.

Conclusion​

While Pinecone holds a prominent position in the vector database domain, its complexity may present challenges for certain users. In contrast, SvectorDB stands out with its straightforward pricing model, extensive client support, and notably lower costs, making it an appealing choice for those seeking an efficient and budget-friendly vector database solution.

At a glance, LanceDB and SvectorDB may appear quite similar as both are vector databases designed for storing and querying high-dimensional vectors. However, subtle yet crucial distinctions exist between the two, making them suitable for different scenarios. In this comparative analysis, we will explore the nuances of LanceDB and SvectorDB, helping you determine which one aligns better with your specific use case.

Architecture​

LanceDB, a Rust-based embedded vector database, operates as a library integrated into your application. This library relies on standard object storage like S3 or GCS. In contrast, SvectorDB is an API-centric vector database accessed through HTTP.

The architectural disparity means that LanceDB impacts application performance since processing occurs in the same process. Conversely, SvectorDB avoids this issue. The significance of this difference varies depending on the application—some may find it a deal-breaker, while others may not.

Client support​

Both LanceDB and SvectorDB offer native Python and JavaScript/TypeScript libraries. However, SvectorDB goes a step further by providing an OpenAPI specification, enabling the automatic generation of client libraries for any programming language.

This flexibility ensures that if your chosen language is not supported by SvectorDB, you won't need to create a custom client library—a convenience not offered by LanceDB.

Updates​

Both databases support updates and deletions, but the implementation varies. In LanceDB, writes necessitate all clients to load new segments, while in SvectorDB, updates are instantly available to all clients. LanceDB's reliance on object storage can pose challenges with small writes, generating inefficient small objects that impact read and write efficiency. Although LanceDB addresses this with a compaction process, it introduces performance issues. Compaction is slow and causes large CPU spikes.

LanceDB excels in large bulk writes, making it ideal for scenarios involving extensive data ingestion in batch jobs. Conversely, SvectorDB is better suited for dynamic data requiring real-time updates.

Serverlessness and cold starts​

Both LanceDB and SvectorDB are categorized as serverless databases. However, the embedded nature of LanceDB demands more resources, potentially causing performance challenges in environments like AWS Lambda. Each new Lambda instance needs to load the dataset into memory, resulting in considerable cold start latency. SvectorDB, being an API-based database, avoids this predicament.

Conclusion​

In conclusion, SvectorDB proves to be the superior choice for serverless applications or those demanding real-time updates. On the other hand, LanceDB may be a better fit for applications requiring bulk index updates, provided the clients can tolerate cold starts. Understanding the strengths and weaknesses of each database is essential for making an informed decision tailored to your specific requirements.