Is my index too expensive to maintain? I just indexed a view that returns 126 millions rows.

There's a process that uses this view to update rows using a trigger and it's by far the most expensive process in my database. 

I'm monitoring this new index usage DMVs and I'm getting a strong feeling that there's too much processing power involved in maintaining this index to balance it's usefulness.

Running the query bellow, it tells me that every 2-5 seconds there's one user seek on this index. During the same timeframe there will have been around 250-1000 user updates. Since it's creation 15 minutes ago, USER_SEEKS=386 while USER_UPDATES=102 876.

Is there a magic ratio where you can safely say it's not worth it to maintain such an index ?

SELECT OBJECT_NAME(S.[OBJECT_ID]) AS [OBJECT NAME], 
       I.[NAME] AS [INDEX NAME], 
       USER_SEEKS, 
       USER_SCANS, 
       USER_LOOKUPS, 
       USER_UPDATES 
FROM   SYS.DM_DB_INDEX_USAGE_STATS AS S 
       INNER JOIN SYS.INDEXES AS I ON I.[OBJECT_ID] = S.[OBJECT_ID] AND I.INDEX_ID = S.INDEX_ID 
WHERE  OBJECTPROPERTY(S.[OBJECT_ID],'IsUserTable') = 1
       AND S.database_id = DB_ID()
       and I.NAME ='&lt;index_name_goes_here&gt;'
Is there a magic ratio where you can safely say it's not worth it to maintain such an index ?

There is not a magic number that exist. You might have an index that is used rarely (compare to number of updates) but supporting that query is important for your business/users.

It is a call that only you can make based on your business/user requirement.

If you want to test, do not drop the index. You can disable the index that way your metadata about the index is preserved. Here is a good post about that.

Disabling vs. Dropping Indexes by Jes Borland.