Manage database tables and vectors

Distinguish row inspection, emptying, dropping, and vector removal.

Database and vector connections expose management controls for the resources they contain. These controls operate on the connected resource, so review the resource name, account, and dependent workflows before making changes.

Database tables

Open the connection's tables surface, choose a table, and inspect its rows. Where a row has a stable address, open the row's own detail page. Return to the table to continue browsing instead of confusing an individual row with the full dataset.

Emptying a table removes its rows while leaving the table available. Dropping a table removes the table itself. A workflow that expects that table can fail after a drop even if the connection still tests successfully. Cancellation of a confirmation leaves the table unchanged; once a destructive operation is confirmed, verify its recorded result.

Use the available empty or drop actions only for a table you intend to affect. If the goal is to discard workflow output records in Strive, use Data source deletion instead. A provider database table and a Strive Data source are different resources.

Vector stores

Inspect the vector surface to identify the collection and selected delivery entries. Delivery entries can repeat a vector reference and are not an exact count of stored vectors. See vector deliveries and deletion. Removing a vector removes the indexed representation from that store. It does not establish that the original document, its imported App copy, or every other indexed representation has also been removed.

Before clearing or deleting a collection, check the workflows that populate it and the retrieval experiences that query it. If an indexing workflow remains active, a later run may add data again. Coordinate data cleanup with the process that produces it.

For structured tables inside an App, see App tables; their ownership, editing, and evidence behavior differ from provider database administration.