Vector databases have quietly become one of the most talked-about components in enterprise AI infrastructure, yet many Australian IT teams reach for one before they fully understand what the technology actually does. The confusion is understandable. Vendors market them as prerequisites for any serious AI deployment, and the category has exploded from a handful of specialist tools to a crowded market in less than three years. The reality is more nuanced: vector databases solve a specific problem extremely well, and they're largely unnecessary when that problem isn't yours.
What a vector database actually does
A vector database stores and indexes high-dimensional numerical representations of data, called embeddings. An embedding is what you get when a model like OpenAI's text-embedding-ada-002 or a locally hosted sentence transformer converts a chunk of text, an image, or an audio clip into a fixed-length array of floating-point numbers. Those numbers encode semantic meaning. Two sentences that say the same thing in different words will produce embeddings that sit close together in the vector space. Two sentences about completely different topics will sit far apart.
The database's job is to answer one question quickly: given this query embedding, which stored embeddings are nearest to it? That operation is called approximate nearest-neighbour search, or ANN search. Doing it at scale across millions or billions of vectors in milliseconds requires specialised indexing structures like HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index). A standard relational database can't do this efficiently. A key-value store can't either. That's the gap vector databases fill.
The most common production use cases in Australian enterprises right now are semantic search, retrieval-augmented generation (RAG) pipelines, recommendation engines, and duplicate or near-duplicate detection. Each of these requires finding semantically similar content quickly, not just exact keyword matches.
The main options and how they differ
The three most widely deployed vector database options in Australian enterprise environments are Weaviate, Pinecone, and pgvector (the PostgreSQL extension). They sit in quite different positions.
Weaviate is a purpose-built vector database with native multi-tenancy, a GraphQL API, and built-in support for hybrid search (combining vector similarity with keyword filtering). It runs on-premises or in the cloud and is increasingly popular in Australian teams that need data residency control. Pinecone is a managed cloud service that trades flexibility for ease of operation: you get fast ANN search with minimal infrastructure overhead, but your data lives in Pinecone's cloud and egress costs can surprise you at scale. pgvector is an extension that adds vector search to an existing PostgreSQL instance. It's not as fast as the purpose-built options at very large scale, but for teams already running Postgres it's often the least risky starting point.
Qdrant and Milvus round out the serious contenders. Qdrant is Rust-based, fast, and fully open-source with a clean REST and gRPC API. Milvus targets very large-scale deployments and has strong support for GPU-accelerated indexing, which matters if you're building embedding pipelines at petabyte scale. Most Australian enterprise teams don't need Milvus; most are better served starting with pgvector or Weaviate.
When you actually need one
You need a vector database when your application must retrieve semantically similar content from a large corpus in real time. The threshold where pgvector starts to strain is roughly 1 million vectors with latency requirements under 50 milliseconds. Below that threshold, pgvector handles the load comfortably on standard hardware.
The clearest signal that you need a purpose-built vector store is a RAG pipeline serving concurrent users against a knowledge base larger than a few hundred thousand documents. If you're building AI agents that retrieve context from a large internal document corpus, the retrieval step will become your bottleneck fast. A well-tuned Weaviate or Qdrant instance with an HNSW index handles this; a naive Postgres query against a vector column does not.
Semantic search is the other common case. Keyword search fails when users phrase queries differently from the documents that answer them. A product support portal where customers ask "why does my screen go dark?" should surface documents about power management, not just documents that contain the phrase "screen goes dark." Vector search solves this. It's one of the quickest wins available to Australian enterprise teams with existing document repositories.
When you probably don't need one
You don't need a vector database if your AI application doesn't involve retrieval. A classification model that takes structured input and returns a label has no use for one. A fine-tuned model that answers questions from its own weights, without pulling in external documents, doesn't need one either. Teams often introduce vector databases into architectures where the actual bottleneck is somewhere else entirely, adding operational complexity for no gain.
You also don't need one if your corpus is small. Under 100,000 vectors, pgvector with a basic IVF index is indistinguishable from a purpose-built store for most query patterns. The cost of operating and maintaining a separate vector database service rarely justifies itself at that scale. Start with pgvector, measure, and migrate only when you hit a genuine performance wall. That's a more defensible procurement decision than pre-emptively buying into a managed service.
Practical considerations for Australian IT teams
Data residency is the first constraint. If your corpus includes personal information covered by the Privacy Act, or if your organisation operates under sector-specific rules (health records, financial data), you need a deployment model that keeps embeddings within Australian borders. Pinecone's managed service stores data in US regions by default; check this before you commit. Weaviate, Qdrant, and Milvus can all be self-hosted on AWS Sydney, Azure Australia East, or GCP Sydney, which resolves the residency question.
Cost is the second constraint. Embedding generation isn't free. Every document you index requires an inference call to an embedding model. At 10 million documents with an average length of 500 tokens, you're looking at 5 billion tokens of embedding generation before you've served a single query. Factor that into the build cost, not just the storage cost. Then factor in reindexing: if your embedding model changes, you re-embed everything. Token costs in AI deployments compound faster than most teams anticipate, and embedding pipelines are a common source of surprise spend.
Index configuration is the third. HNSW's M and ef_construction parameters directly control the trade-off between search speed, recall accuracy, and memory consumption. Leaving them at defaults is fine for prototyping. In production, wrong settings mean either poor recall (your search misses relevant documents) or excessive RAM use. Test your specific corpus and query distribution before locking in a configuration. No vendor default is optimised for your data.
Getting started without overengineering it
The pragmatic path for most Australian enterprise teams is: start with pgvector in your existing Postgres instance, use a well-supported embedding model (OpenAI's text-embedding-3-small is cost-effective; Cohere's embed-v3 is strong for multilingual or domain-specific corpora), and measure retrieval latency and recall against your actual query workload. If latency exceeds your threshold or recall drops below acceptable levels as the corpus grows, migrate to Weaviate or Qdrant. The migration is straightforward because the data model is simple: vectors, metadata, and IDs.
The teams that end up with the cleanest vector search implementations are the ones that defined their retrieval requirements before picking a database. Query latency target, corpus size, update frequency, concurrent user load, and data residency requirements are the five numbers that determine which option fits. Start there, not from a vendor shortlist.