Vector DB Dynamic Filtering

Good morning, here’s a draft template you can use for your Retool forum post to clearly communicate your issue:

Goal:

I’m aiming to have dynamic metadata filters for the Wiens database in my Retool app. Specifically, I need the metadata input box on the upsert document function for the retail vector resource to dynamically reference incoming data using curly braces (just like other parts of Retool). This would enable an automated workflow for populating new documents across various databases without manually typing filter values each time.

Steps:

• I created the tags for the Wiens database filters.

• I attempted to add dynamic values (using curly braces) to the metadata input, similar to other parts of Retool.

• I consulted the Retool documentation on App JSON export and metadata configurations, but haven’t found a way to make the metadata input dynamic.

Details:

Issue: When upserting a document, the metadata input box does not accept dynamic references. Instead, it only allows static text, making the filtering functionality ineffective for automated workflows.

Example:

// Expected behavior: dynamic referencing similar to other Retool fields
{
  "filter": "{{ yourDynamicValue }}"
}
// Actual behavior: the metadata field requires manually typed values.

• There are no specific error messages—the field just doesn’t interpret the dynamic syntax.

Screenshots:

Hi @SplinteredGlassSolutions,

Thanks for the detailed report! I am sharing this with our team and will follow up here when they ship a fix

Hey @SplinteredGlassSolutions — Alex here from the Retool team :wave:

I also ran into this issue and searched the forums looking for a fix and found your post. After some digging, I discovered a workaround that might help you.

While we don't yet support adding dynamic {{ }} references in the Metadata field of the Upsert Document action in the Retool Vector block, you can add this metadata manually after the document has been upserted.

The workaround involves writing to your RetoolDB instance directly, since each Retool Vector Store is actually located in a unique table in the public schema in your Retool DB instance.

Steps to update the metadata:

  1. First you need to query your RetoolDB instance to identify the correct table for your vector store. You can use this query and run it in the query library, or in any RetoolDB query block. The goal of this is to get the table name in RetoolDB where we store the documents in your Vector Store.

Query:

SELECT
  table_schema,
  table_name
FROM information_schema.columns
WHERE 
  table_schema = 'public'
  and table_name ilike '%__retool_vector%' 

Example Results:

You will just have to comb through the results to find the table name that matches the name of your Vector Store. For example, a Vector store with the name "Tapper Test Vector" might have a table name that looks like __retool_vector_tapper_test_vector_fc56febe_b2ed_6291_e

  1. Add a RetoolDB block after your Retool Vector block to update the metadata. You will need a unique identifier, either in the metadata or the name field of your vector document, in order to update the correct file. In my case, I can rely on the name field being unique — it's defined earlier in the workflow along with the metadata. The metadata value that I'm passing is just a JSON object.

Example query:

UPDATE public.__retool_vector_tapper_test_vector_fc56febe_b2ed_6291_e
SET metadata = {{ formatMetadata.data }}::jsonb
WHERE source = {{ formatData.data.fileName }}

Screenshot of the update block

Once the second query runs, you will see the updated metadata on the document you uploaded to the vector store.

Hope this helps!

3 Likes

This is fantastic information—thank you for detailing the workaround! I hadn’t realized it was possible to interact with the Retool Vector database directly through standard SQL queries. That definitely opens up a lot of possibilities for customizing workflows and managing metadata dynamically. Really appreciate you sharing this!

3 Likes

for anybody curious, the Retool DB uses the PGVector(docs) extension of PostreSQL and not the newer PGVectorStore.... or as of right now anyway :innocent:.

1 Like