Has anyone tried using LlamaIndex with Supabase Vector DB?

Alright, let's get this started because I've wasted a weekend on this and you shouldn't have to. I'm evaluating LlamaIndex for a new RAG pipeline, aiming to replace a clunky, multi-stage Jenkins monstrosity that takes 45 minutes just to generate embeddings. The idea was simple: use Supabase's built-in vector DB (which is just pgvector under the hood) to keep things in one place and hopefully make the CI/CD for our doc updates less of a crawl.

Here's the blunt review after hacking through it: it *works*, but the path is littered with sharp edges and outdated documentation. The `SupabaseVectorStore` is functional for basic operations, but you're going to hit friction points if you need anything beyond the trivial "ingest and query."

My main gripes, in no particular order:

* **Connection Pooling & Performance:** The official integration examples often show a new client instantiated per operation. In a pipeline step processing hundreds of documents, that's a one-way ticket to connection limit town. You need to manage the Supabase client lifecycle yourself.
* **Metadata Handling:** Supabase stores metadata as JSONB, which is fine. However, I've seen inconsistencies with nested filters when using the `VectorStoreIndex` abstraction. You often fall back to writing raw SQL queries via the client, which defeats the purpose of using the LlamaIndex abstractions in the first place.
* **Incremental Updates:** This was the big one for me. Our docs repo gets minor updates constantly. The process for updating only *changed* embeddings, without a full rebuild, required a custom script. The built-in tooling isn't pipeline-friendly. You'll be writing more orchestration code than you'd like.

Here's a snippet of the least-worst way I found to get a batch ingestion working reliably in a GitHub Actions step, after the poetry installs and whatnot:

```python
from llama_index.vector_stores.supabase import SupabaseVectorStore
import os

# Initialize the store directly, not through the high-level wrapper
supabase_client = supabase.create_client(
os.environ["SUPABASE_URL"],
os.environ["SUPABASE_SERVICE_KEY"]
)

vector_store = SupabaseVectorStore(
supabase_client=supabase_client,
table_name=os.environ.get("TABLE_NAME", "documents"),
embedding_dimension=1536 # Match your embedding model
)

# Build your index from documents
storage_context = StorageContext.from_defaults(vector_store=vector_store)
index = VectorStoreIndex.from_documents(
documents,
storage_context=storage_context,
show_progress=True # At least you get a progress bar
)
```

The real trick is what you do *after* this. For any non-toy implementation, you'll need to:
* Implement a checksum or last-modified check on your source documents to skip unchanged ones.
* Handle deletes from the source in your vector DB (a manual `delete()` query).
* Monitor your Supabase compute time, as bulk inserts/upserts can spike CPU.

In the end, it got the job done and the pipeline now runs in under 10 minutes, but the "batteries-included" feeling wasn't there. If your use case is simple, go for it. If you have dynamic data and need robust, incremental pipeline steps, be prepared to get your hands dirty and write the glue code yourself.

So, has anyone else been down this road? Did you find a cleaner way to handle incremental syncs, or did you just accept the full-rebuild tax? I'm especially interested in how you might have integrated the update logic into a GitOps-style workflow.

fix the pipe