How to use this demo

1. What you are looking at

This demo is one PostgreSQL database, finance, that you can read but not change. Most of its data is public (SEC filings, US economic series, the S&P 500 list), plus a few tables of invented rows that look like card, salary and credential data. DBSheriff watches what you run and reacts, with no agents, no proxies and no application changes: it sees a running statement within a few seconds of its starting, responds in about one to three seconds, and ends the session through PostgreSQL's own controls after the statement has started, not before it runs.

2. The doors

The monitor, https://demo.dbsheriff.ai/, is where you watch DBSheriff react. Everyone uses one shared login, the same as on the landing page:

User name
demo
Password
vumegu-lupafo-topori-356

Open the landing page and press Enter the demo. Signing out is switched off; close the tab when you are done.

The SQL box, https://sql.dbsheriff.ai/, is where you type SQL and see rows. It needs a login of your own (next section).

The API, https://api-demo.dbsheriff.ai/, runs the same SQL over HTTP, with curl and your token.

The admin console, https://demo.dbsheriff.ai/admin/, takes the shared login too. Section 7 covers it.

3. Get your own login

  1. Open sql.dbsheriff.ai/signup, or press Request your own login on the landing page. If sign-ups are paused or the demo is full, come back later.
  2. Enter your e-mail address, tick the terms box, pass the bot check and press Send me a sign-in link. The label of the terms box repeats the public notice of section 4: what you later run in the SQL box is shown publicly.
  3. The e-mail, "Your DBSheriff demo sign-in link", holds a link that works once and expires 15 minutes after you ask. No mail? Check spam, and use a regular address: temporary-mail domains get no mail, and nor does an address that asks many times in a short while.
  4. Open the link and press Sign in (JavaScript and cookies needed). Your API token, starting dbsd_, is shown once; copy it to use the API.
  5. Press Continue to the SQL box. Your PostgreSQL login is made when you run your first statement (section 4).

Every sign-in makes a new API token, and the old one stops working. Lost your token? Request another sign-in link on the sign-up page with the same address; signing in again makes a new token.

4. Try it in the SQL box

Open sql.dbsheriff.ai/app, paste one statement and press Run. The Examples panel holds ready-made ones, and the schema page lists every table and column.

Everything you run is public. The SQL you run, including any values and comments inside it, is shown publicly on the monitor next to your pseudonym and kept. Do not put personal data or secrets in it.

Six tables are sensitive: balance_sheet, income_statement, insider_transactions (real filings) and financial_data.credit_cards, hr_schema.salaries, system_auth.credentials (invented rows). Two decoys, card_vault_archive and hr_salaries_export, are bait: a read of either is flagged when DBSheriff sees it. The other nine are regular: cash_flow, shareholders_equity, securities, index_membership, macro_series, macro_observations, date_dimension and the views pension_funds and us_ownership_by_sector.

Start with your pseudonym (one row), then the list of tables and views (what exists, not which are sensitive). The list also shows two views, pg_stat_statements and pg_stat_statements_info, which belong to the database's statistics extension, not to the dataset:

SELECT current_user
SELECT table_schema, table_name FROM information_schema.tables WHERE table_schema NOT IN ('pg_catalog', 'information_schema') ORDER BY table_schema, table_name LIMIT 50

Your login is made when you run your first statement. After it, the line above the box reads "Your postgresql login is dvp.... Look for it on the monitor." That name, dvp plus ten letters and digits, is your pseudonym: write it down, because the monitor shows it next to what you run.

Regular tables

Expect rows back. The last ten cash-flow filings of one company:

SELECT symbol, period_end, period_type, operating_cash_flow FROM cash_flow WHERE symbol = 'AAPL' ORDER BY period_end DESC LIMIT 10

One row per sector:

SELECT gics_sector, COUNT(*) AS companies FROM securities GROUP BY gics_sector ORDER BY companies DESC

Ten rows from a view:

SELECT date, pension_type, metric, value FROM pension_funds ORDER BY date DESC LIMIT 10

Sensitive tables

A statement here may be ended, whatever its size: expect the rows, or an ended session. DBSheriff can only end a statement that is still running when it looks, so a quick read may finish first and be flagged afterwards. Five income-statement rows:

SELECT symbol, period_end, revenue, net_income FROM income_statement WHERE symbol = 'AAPL' ORDER BY period_end DESC LIMIT 5

Five rows of the invented card table. Keep the schema name:

SELECT * FROM financial_data.credit_cards LIMIT 5

A bulk read of about two million insider trades, with no LIMIT: the statement DBSheriff is built to end. The demo keeps the first 200 rows and reads and discards the rest, so the statement keeps running for as long as that read takes, and DBSheriff can end it only if it sees it while it is still running. The box says "Running..." and shows rows only when the statement ends: the first rows, marked "at least; the list is cut"; or "The database closed your session while this statement was running." if it was ended first; or a "ran too long" message at the 30 second limit. Do not repeat it many times (section 8).

SELECT symbol, filing_date, transaction_code, shares, price_per_share FROM insider_transactions

Decoy table

Five rows of a decoy. It is not one of the six sensitive tables, so its row carries a different reason from them (section 6):

SELECT * FROM card_vault_archive LIMIT 5

5. Try it with the API

First put your token in a variable: export DBSHERIFF_TOKEN= followed by the token you were shown. These run in bash or zsh; on Windows use the SQL box or a bash shell such as WSL. The SQL box's Copy as curl button writes the same call with the same variable. The commands print only the body, so tell the answers apart by the code word in error.code, not by a number (add -i to a command to see the status line too). On your first query you may get unavailable: see the list at the end of this section.

1. Who am I: your state, your expiry and, under engines, your pseudonym as login (null until your first statement).

curl -sS https://api-demo.dbsheriff.ai/v1/me \
  -H "Authorization: Bearer $DBSHERIFF_TOKEN"

2. The tables, no token needed. Each has a group: sensitive_real and fixture_synthetic are the sensitive ones, decoy the bait, normal_real the regular ones. The quotes keep zsh happy. Names come without their schema, so write financial_data.credit_cards in SQL.

curl -sS "https://api-demo.dbsheriff.ai/v1/tables?engine=postgresql"

3. A regular table. The body holds engine, statement and an optional max_rows; the answer holds your login, the columns and the rows.

curl -sS -X POST https://api-demo.dbsheriff.ai/v1/query \
  -H "Authorization: Bearer $DBSHERIFF_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{"engine": "postgresql",
 "statement": "SELECT gics_sector, COUNT(*) AS companies FROM securities GROUP BY gics_sector ORDER BY companies DESC",
 "max_rows": 20}
JSON

4. A sensitive table: you get the rows, or statement_ended (HTTP 409).

curl -sS -X POST https://api-demo.dbsheriff.ai/v1/query \
  -H "Authorization: Bearer $DBSHERIFF_TOKEN" \
  -H "Content-Type: application/json" \
  --data-binary @- <<'JSON'
{"engine": "postgresql",
 "statement": "SELECT symbol, period_end, revenue, net_income FROM income_statement WHERE symbol = 'AAPL' ORDER BY period_end DESC LIMIT 5"}
JSON

To run another statement from section 4, put it in the statement field on one line. The answers:

6. Watch it in the monitor

  1. Open the landing page, press Enter the demo and sign in with the shared login.
  2. Under Monitoring, open Live Feed: the latest statements of the last hour, then new ones as they are scored, from all visitors.
  3. Type your pseudonym (dvp...) in the User box, then run a statement.
  4. Your row shows server pg-01, database finance, your pseudonym under DB User, Duration, Risk, Score, Reasons and Query. Click it for details; the Reason Codes tab under Governance explains each code.

How long it takes. DBSheriff sees a running statement within a few seconds of its starting and responds in about one to three seconds. A statement that finishes before DBSheriff looks is counted afterwards, shows the Duration DONE and cannot be ended.

A normal row. Reads of regular tables are the ordinary case: Safe means DBSheriff scored the statement below its risk line, and a ▶ with seconds in Duration means it was seen still running.

A flagged row. A statement on one of the six sensitive tables gets the reason R30, "touched a table classified as sensitive", which lifts its score to the level at which DBSheriff ends a session. Risk then reads High Risk if the statement had finished, or Kill (the monitor's word for an ended session) if it was still running and so could be ended. In the product's rules a read of a decoy table gets a reason of its own, R64, and not R30; the Reason Codes tab explains it.

An ended statement. Its Live Feed row reads Kill, as above. The separate record that the session was actually ended is in History (under Monitoring): set Type to Killed only and press Search. History does not refresh itself, so search again if your row is missing. It shows the last 24 hours unless you change the range, and it has no User box: click the DB User column heading to sort, or use your browser's find (Ctrl or Cmd plus F) for your pseudonym. Locked users only lists locked logins, and the Overview tiles Killed Queries and Locked users count both.

7. Run a compliance scan

This is the admin console, https://demo.dbsheriff.ai/admin/. Sign in with the same shared login as the monitor; everyone shares it, so scan history and findings are shared too. There are three things to run here and they are independent. Start with the compliance report (the Compliance Scan tab); the classification scan and the posture scan are optional extras. Only the buttons named in this section work: the rest of the console is view only, and the demo refuses the other buttons, so please leave them alone. The Server pickers may list other servers; only pg-01 is open, so always pick pg-01.

The compliance report

  1. In the left menu, under Security & Access, open Compliance Scan. It builds a report, after first re-checking security posture.
  2. From and To start at about the last 30 days, ending yesterday, and the To day counts. To include what you ran today, set To to today.
  3. Under Server pick pg-01. That also sets Engine.
  4. Press Download HTML report or Download CSV bundle. A new tab opens and waits while the console re-checks posture (at most 90 seconds, skipped if a scan is running) and builds the report. Keep it open. If no tab opens, allow pop-ups for this site and press the button again. Your browser then saves a compliance_... file, HTML or a ZIP of CSV files.
  5. Among other sections it covers an executive summary, sensitive-data access, schema changes, privilege escalation, ended statements, per-user access to sensitive tables, and posture findings and results. If you ran a statement on a sensitive table in the period, search for your pseudonym (your browser's find, Ctrl or Cmd plus F, in the HTML report; open the CSV files in the ZIP) in the sensitive-data access and per-user access sections, and in the ended-statements section if a statement of yours was ended. Reads of regular tables are not listed there.

This is a compliance evidence report. Any framework references in it are DBSheriff's own mapping, not reviewed by a QSA or an auditor; a QSA or auditor must confirm them. In the posture results, PASS and FAIL are DBSheriff's own check results, not a statement that any control is met.

The classification scan

  1. Under Data Governance, open Classification Scan.
  2. Keep PostgreSQL under DB flavor(s), pick pg-01 (postgresql) under Server, leave Database blank and Min tier (the lowest sensitivity level to list) on SENSITIVE, and press Run scan.
  3. Open the Results heading (closed until clicked) and press Refresh, next to Run scan: the scan shows RUNNING, then COMPLETED with its candidate count. It can also end FAILED or SKIPPED, or COMPLETED with a warning mark you can click for the reason.
  4. A candidate is a table or column the scan proposes to label as sensitive. Candidates are listed under Data Governance, Classifications, normally as Pending review; the demo does not offer approving them. A candidate's note may ask you to "verify manually": that is the scan asking a person to check, not an error.

The posture scan

  1. Under Security & Access, open Security Posture.
  2. Pick pg-01 (postgresql) and press Run posture scan. The console's own text calls the monitor the "Reporting UI".
  3. No running row appears. Open Results and press Refresh, next to the scan button, now and then: the scan appears as a row when it ends, with its checks, its findings and a status, OK or ERROR. The findings are in the monitor, under Security, in Posture.

If a scan is already running. The console runs one scan at a time for the shared login, so someone else's can hold the place. A message such as "a scan of yours is still running" shows for only a few seconds at the bottom right, where the demo's own links can partly cover it: wait, then press the button once more. If you see no message, wait a little and press the button once more. A report tab that says "429 Too Many Requests" needs several minutes.

What a scan records. A scan reads metadata from the demo database (table and column names and, for a few kinds of column such as card numbers and e-mail addresses, a small sample of values, for the classification scan; roles, grants and settings for the posture scan) and writes its results to DBSheriff's own records, which anyone using the shared login can see.

8. Rules and limits