Connecting your data platform — the concepts

Teksoptima analyses the usage metadata your data platform already keeps about itself — what ran, on which compute, for how long, and what it cost. It never needs your tables, rows or files.

This page explains the ideas that are the same on Snowflake and Databricks. Then read the page for your platform:

• Connecting Snowflake
• Connecting Databricks

1. What we read, and what we don't

On both platforms this metadata lives in a built-in, read-only system area (SNOWFLAKE.ACCOUNT_USAGE on Snowflake, the system catalog on Databricks). Access to it is a separate permission from access to your business data, so granting one never grants the other.

Query text is opt-in on Databricks. SQL text can contain business values (a customer name in a WHERE clause), so it is left out unless you turn it on. Every screen works without it; only the SQL previews disappear.

2. Two ways to connect

Every connection is one of two modes. They run the same queries against the same system tables and feed the same screens. They differ in who starts the run and who holds a credential.

Push is the default because it is the smaller ask. You run code you can read, in your own account, and the only thing that crosses the boundary is the finished upload. There is nothing for you to rotate on our side and nothing of yours for us to lose.

What "push" actually sends

Your account                                         Teksoptima
────────────                                         ──────────
Scheduled job reads the system views
  → builds a JSON payload (aggregated, not raw)
  → gzips it
  → HTTPS POST with the upload token in a header ──► validates it, stores a snapshot
                                                     → the screens read the snapshot

Large uploads are sent in parts and only become visible once the last part is committed, so you never see a half-finished snapshot.

What "pull" does differently

You give us a credential scoped to the system tables. We exchange it for a short-lived access token, run the same queries on a small warehouse you designate, and store the results as a snapshot. We don't query your account every time you open a page: that would keep your compute awake and billed — the exact waste this product exists to find.

3. Snapshots, not a live feed

Screens read the latest stored snapshot, not your account in real time.

• Push: a new snapshot arrives each time your job runs (daily by default).
• Pull: a new snapshot is taken by a daily job, or when you press Refresh now.
• Usage views on both platforms have their own lag (Snowflake ACCOUNT_USAGE can trail by a few hours; Databricks billing can restate recent days), so very recent activity may not appear yet. This is a property of the platforms, not of the connection.

We keep your 30 most recent complete snapshots and delete older ones daily. Uploads that never finished are deleted after 24 hours.

4. Who needs to do what

Connecting is a one-time setup that needs an administrator of your data platform, because granting access to system metadata is an admin action on both platforms:

If you aren't an admin, the setup pages are written so you can hand the exact script or steps to one.

5. Staying in control

• Everything we do is visible in your own logs. Queries from a pull connection show up in your platform's query history and audit logs under the identity you created. Push jobs show up as your own scheduled job.
• Read-only. There is no write access. Recommendations are commands for you to review and run yourself.
• Revocation is yours and instant. Revoke the grant, delete the secret, drop the job, or regenerate the upload token — each takes effect immediately.
• Disconnecting deletes. Removing a connection deletes its stored credentials, tokens and every snapshot. Deleting your account deletes all of your workspaces the same way.

The full list of what we claim, and the code behind each claim, is on the Security page (/security in the app).

6. Glossary