You Don't Need A Separate Vector Database

We've all been there. Your application starts out simple:

Store your application data in a database (Postgres, SQLite, MySQL)
Add a vector database for embeddings
Throw in Elasticsearch for text search
Add Redis for caching and background jobs

Suddenly, you're juggling multiple databases, each with its own scaling, backup, and sync challenges. Updates to data are now more complex as one system needs to sync with another, refresh a cache, re-rank embeddings, and so on.

Modern databases have come a long way. We've already seen how they can handle full-text search natively, manage background jobs through native queuing, and support complex caching strategies. Vector search isn't any different – it's just another capability that belongs in your primary database.

Whether you're using pgvector, sqlite_vec, or Turso's native libSQL vector datatype, that's maybe all you need.

#The Hidden Costs of Separation

Vector Databases Are the Wrong Abstraction highlights a common scenario:

You're building a RAG system, and your team uses Pinecone as a vector database to store and search embeddings. But you can't just use Pinecone—your text data doesn't fit well into Pinecone's metadata, so you're also using DynamoDB to handle those blobs and application data. And for lexical search, you needed OpenSearch. Now you're juggling three systems, and syncing them is a nightmare.

Thankfully, this complex "best of breed" microservice architecture when it comes to vector databases isn't necessary. It's costing you more to run and maintain this type of architecture than it would be if you used a database that could do it all.

Some databases aren't cut out to do it all though.

#Features of a Vector Database

It's worth noting that vector databases do provide features beyond just storing and search embeddings:

Automatic Re-ranking
Hybrid search and relevance scoring
Embeddings compression

Not all applications require these features though. You'll probably find yourself comparing the trade-offs from managing the complex sync process from before to now managing jobs that re-rank or combine searches.

Consider Turso's approach:

CREATE INDEX movies_idx ON movies(
  libsql_vector_idx(
    embedding,
    'metric=cosine',
    'compress_neighbors=float1bit'
  )
);

This gives you:

Efficient similarity search using DiskANN
Vector compression (including 1-bit quantization)
Combined queries with SQL filters

For many applications, this is more than sufficient. If you do need more specific vector database features, consider whether the complexity cost of managing a separate system is worth it.

#Turso Vector Search

Rather than treating vector search as something that requires a separate database, database providers like Neon, PlanetScale, and Turso are beginning to integrate vector capabilities directly into their core functionality.

Since Turso's SQLite offering is based on a SQLite fork — libSQL, it is able to add a native datatype that deals with vectors, skipping the need to plug-in to any hooks like you would with an extension.

Here's what this means in practice:

CREATE TABLE movies (
  title TEXT,
  year INT,
  embedding F32_BLOB(4)  -- Vector embedding alongside data
);

SELECT title, year
FROM movies
WHERE year >= 2020
ORDER BY vector_distance_cos(embedding, vector32('[0.064, 0.777, 0.661, 0.687]'))
LIMIT 3;

Storing vectors right alongside your regular data has several advantages:

Query Flexibility — Combine similarity search with regular SQL queries.
Simplified Operations — One database to backup, monitor and scale.
Unified Data Model — Vectors are right alongside your relational data, no more sync overhead.
Atomic Updates — Update your data and embeddings in a single transaction.
Cost Efficiency — Fewer bills, less setup.

Learn more about Turso Vector.

#The Real World

Instead of defaulting to a separate vector database, consider starting simple, monitoring requirements, and evaluating the trade-offs.

#Mobile AI

Kin, a mobile app offering a personal AI assistant, leverages Turso's vector search to perform all operations locally, on-device. This enables them to maintain user privacy.

#Multi-tenant AI Applications

Adaptive Computer uses Turso's platform to spin up ephemeral databases for AI agents, each containing regular application data and vector embeddings. This unified data model allows them to easily manage thousands of AI workspaces without the complexity of synchronising multiple systems.

#Embedded Databases

Modern applications need more than just vector search — they need a complete solution that works everywhere with support for:

Regular CRUD operations
Full-text search
Vector similarity search
Fast reads and writes that work offline
Zero network latency

Turso already boasts a feature not applicable to most database providers — Embedded Replicas, all thanks to SQLite being just a file. You can embed a file on-device that users can read from, enabling ZERO network latency.

Soon, you will be able to write to this file locally with Offline Writes — join the beta.