Vector databases
A managed vector database that is just PostgreSQL
Store embeddings and search them by meaning, on pgvector we run and back up for you. No new datastore to learn, no cluster to size — create an index, write your vectors, and query it with the API key you already have.
The database you already trust, with one extra column type
A vector database is usually a second system to run alongside the first: another cluster, another backup story, another thing to be woken up for. This is pgvector inside PostgreSQL — the same engine, the same durability, the same nightly base backup and continuous write-ahead log archiving that everything else here gets. Your index is an ordinary table with an HNSW index on it, so it is fast for approximate nearest-neighbour search and boring in every other respect, which is the property you want at three in the morning.
Your model's width, not a width we picked
Most managed vector services make you choose from a short list of dimensions. Yours does not have to be a round number: anything from 1 to 3072 is accepted and held exactly, because a narrower vector is padded into the next physical width with zeros — which changes cosine, Euclidean and inner-product distance by precisely nothing. A 1408-dimension model ranks identically to one sized natively for it, and reads give you back the 1408 values you stored, never the padding.
Included on every vector plan
- Any embedding width up to 3072, and cosine, Euclidean or inner-product distance
- Metadata stored with every vector, and filtered on at query time
- Nightly backups with 30-day retention and point-in-time recovery
- Row-level security, so one organisation's vectors are unreachable from another's
Plans and pricing
Three tiers, priced on the two things that actually cost us anything: how much you store and how much you search.
Priced on your configuration
Cost depends on the region, machine size, bandwidth and storage you choose, so there is no single monthly figure we could honestly print here. Tell us the workload and we will quote it.
Powered by 100% renewable energy
Every server we run, on every product, is powered by renewable electricity. Not offset after the fact — sourced that way.
- 100% renewable electricity across all our hosting
- Data centres running at a PUE of 1.1 to 1.2
- Sites on our shared platform pass the Green Web Foundation's checks — a third party you can verify for yourself
Questions people ask before they buy
Which embedding models does this work with?
Any of them. You send us the numbers your model produced, so OpenAI, Cohere, Voyage, a Sentence-Transformers model on your own machine and anything else are all the same to us. You tell us the width when you create the index — 384, 768, 1024, 1536 and 3072 are all common, and so is something in between.
Can I change an index's width or distance function later?
No, and we would rather say so plainly than let you discover it. Both decide where your vectors are physically stored and how they are ranked, so changing either would silently invalidate everything already in the index. If you switch to a different embedding model, create a second index and write into it — the same thing every vector database asks of you, and for the same reason.
Is there anything different about very wide vectors?
Yes, and it is worth knowing. Above 2,000 dimensions the values are stored at half precision, because PostgreSQL's HNSW index does not accept a full-precision column wider than that. For 3072-dimension models this is the approach pgvector itself recommends and the effect on ranking is negligible — but it is a real trade-off and you should hear it from us rather than infer it.
Do I get a database connection string?
Not today. You reach your index over HTTPS with your Zinn® API key, scoped so a key that can search cannot do anything else in your account. That is what lets us meter queries honestly and keep one tenant's rows unreachable from another's. If a direct connection is what you need, tell us — we would rather build it because someone asked than guess.
How is it metered, and can I check the numbers myself?
On two meters: how much you store and how many searches you run in a calendar month. Both are on your dashboard as they happen. Storage is a published formula rather than a physical table size — row overhead, plus the stored width, plus the length of your own ids and metadata — precisely so you can reproduce the figure we are billing you for instead of taking our word for it.