n8n Pinecone vs Supabase Vector Store: Which to Pick

You are building a RAG workflow in n8n and the node picker offers both a Pinecone Vector Store node and a Supabase Vector Store node. They plug into the same agent the same way, so the choice feels arbitrary. It is not. One is a fully managed service you rent, the other is a Postgres extension you run. That single split, managed versus self-hosted, sets your free tier, your bill at scale, and how much you operate.

Pinecone or Supabase for n8n RAG?#

Pick Pinecone when you want a managed vector service that scales to millions of vectors with no database to run, and Supabase when you want your embeddings to sit in the same Postgres as your app data. Both wire into n8n identically, so the real choice is operational, not about retrieval quality.

The mechanics are the same on either side. An Embeddings sub-node turns text into vectors, the vector store holds them, and an AI Agent or retrieval chain queries them at answer time. Swap Pinecone for Supabase and the agent contract does not change. The vector store and embeddings walkthrough covers that shared wiring in full.

Where they part ways is ownership. Pinecone is a fully managed serverless service: you get an index and some namespaces, and there is no machine to patch. Supabase is pgvector, the Postgres extension whose type is literally named vector, running inside a database you own. That means your vectors can sit next to the relational rows you already query. If you are weighing pgvector against other engines, the pgvector, Chroma, and Qdrant comparison widens the field.

There is a subtler reason the picker feels like a coin flip. Both stores return the same documents for the same query, given the same embedding model, so nothing you see in the agent's output tells the two apart. The signal that should drive the decision is invisible at build time: what you will pay in six months, and whether you want a database to own and operate.

Same n8n wiring, different home: one is a managed service you rent, the other is pgvector inside a Postgres you run.

How do the two n8n nodes differ?#

Barely, on the surface. Both are cluster sub-nodes called Pinecone Vector Store and Supabase Vector Store, and each offers the same 5 modes: Get Many, Insert Documents, two Retrieve modes, and Update Documents. The difference is the credential and the target you name, an index and namespace versus a table and query name.

On the Pinecone node you select a Pinecone Index, optionally set a Namespace to segment tenants, and can Clear Namespace before a fresh insert. Get Many exposes a Metadata Filter. The credential is a Pinecone API key, and that is the whole setup, because the index already lives in Pinecone's cloud.

On the Supabase node you set a Table Name, which is required, and a Query Name option that defaults to match_documents, the SQL function pgvector calls to run the similarity search. Update mode takes an ID, and Get Many takes a Metadata Filter. The credential is your Supabase project URL plus a service role key. Both nodes need an Embeddings sub-node feeding them and attach to an agent the same way. For an end-to-end build, the RAG support bot guide wires one from trigger to answer.

In practice you lean on two modes. Insert Documents loads the store during an ingestion run, reading chunks from a splitter and writing their vectors once. A Retrieve mode then serves queries at answer time, either feeding a chain or acting as a tool the agent calls. Keep the embedding dimension identical on both sides, because a store built at one dimension cannot answer a query embedded at another.

The same five steps set up either store; only the credential and the target you name differ.

What does each cost at free tier and at scale?#

Both are free to start and cheap to grow, but the ceilings differ. Pinecone's Starter tier gives 2 GB of storage, 5 indexes, and 1M read units a month. Supabase's free plan gives a 500 MB Postgres shared with your tables. Paid entry is $50 a month for Pinecone, $25 for Supabase Pro.

Turn those limits into vectors. A single 1536-dimension embedding stored as float32 is about 6 KB. Modeled against raw storage, Pinecone's 2 GB holds on the order of 300,000 such vectors before namespaces and metadata, while Supabase's 500 MB, once you count the HNSW index and row overhead in the same database, realistically holds on the order of 40,000. Those are modeled figures from published limits, not a benchmark, and the arithmetic is easy to redo for your own dimension count.

At scale the models diverge. Pinecone Standard bills a $50 a month minimum plus usage, roughly $16 to $18 per million read units, $4 to $4.50 per million write units, and $0.33 per GB of storage each month. Supabase Pro is $25 a month for 8 GB of disk, then $0.125 per GB, and you also pay for the compute size you run. The honest read: Supabase stays cheaper when vectors ride along with data you already keep in Postgres, and Pinecone earns its premium when you need managed scale without owning a server.

The $50 a month minimum is the number that surprises people. Below it, Pinecone Standard still bills $50, so a small production index whose raw usage would cost a few dollars effectively rents the platform. Supabase has no such floor beyond the $25 Pro plan, which is why hobby and low-traffic projects often settle on pgvector and only reach for Pinecone once scale makes the floor irrelevant.

Published free-tier ceilings for each store; both cost nothing until you outgrow them.

Which is faster and easier to operate?#

Pinecone is easier to operate because there is nothing to run: it autoscales and ingested vectors are searchable within seconds. Supabase can be faster per query once you build an HNSW index, but you own that tuning, and a free project pauses after 7 days idle, which can silently break a quiet bot.

Query speed on pgvector depends on the index you build, not on defaults. HNSW gives strong recall and low latency, IVFFlat trades some recall for smaller indexes but needs its list count tuned, and on the shared free CPU either one is modest. Pinecone hands you predictable nearest-neighbour latency without sizing a machine, which is the whole point of paying for a managed service.

Operations tell the same story. Pinecone means no patching, no backups, and namespaces that isolate tenants without extra tables. Supabase means you own upgrades and backups, but you get relational rows and vectors in one place to back up together, which many teams prefer. The 7-day pause is the free-tier trap: an anonymous widget that goes quiet over a weekend can wake up to a paused database, so keep it warm or move to Pro.

The keep-alive is worth spelling out. A scheduled n8n workflow that pings the database once a day holds a free Supabase project open, and it costs nothing beyond a trigger. It is a small tax, but forgetting it is the most common way a demo agent quietly goes dark, so decide up front whether you would rather pay for Pro or run the ping.

The day-two realities that the free-tier numbers do not show.

Which vector store should you pick?#

Default to Supabase when your embeddings belong next to relational data and you want one database to run and back up. Choose Pinecone when you need hands-off scale to millions of vectors, tenant namespaces, or a bot that must not pause. For most n8n builds starting out, either free tier is plenty.

Because the n8n node contract is the same 5 modes on both sides, this is not a one-way door. Start on Supabase free while your corpus is small, and if multitenancy or scale forces the issue, swapping to Pinecone is a node change, not a rewrite. If your retrieval needs keyword precision on top of semantics, pair either store with the pattern in the hybrid search guide.

That reversibility cuts both ways. Moving from Pinecone back to Supabase is just as cheap, so treat the first pick as a sensible default rather than a commitment. The one cost you cannot undo is re-embedding a large corpus, and that is compute time on your embedding model, not lock-in from either store.

One last honest point. The store rarely limits answer quality. Your chunking, your embedding model, and how many results you retrieve move the needle far more than Pinecone versus Supabase does, so pick the operational fit and spend your tuning time upstream.

Start from where your vectors belong, then let scale, ops, and how often the bot runs settle the pick.