Skip to content

Latest commit

 

History

History
103 lines (66 loc) · 2.75 KB

File metadata and controls

103 lines (66 loc) · 2.75 KB

OhMyDB Demo

This demo shows the core OhMyDB safety flow against PostgreSQL:

  1. A normal SELECT passes through the proxy.
  2. A risky UPDATE without a WHERE clause is intercepted.
  3. OhMyDB classifies the operation as critical.
  4. The query is blocked before it modifies the database.
  5. A follow-up query verifies that the data remained unchanged.

Safe demo checklist

Before running the walkthrough:

  • use a disposable local database
  • never point the demo at production
  • reset demo data before repeating the mutation test
  • confirm the client is connecting through the OhMyDB proxy port
  • keep backups and normal database safeguards in place

Start OhMyDB

ohmydb --version
ohmydb

Connect through the proxy

Connect the PostgreSQL client to the OhMyDB listening port rather than directly to the database backend.

Example:

psql -h 127.0.0.1 -p 5433 -U postgres -d ohmydb_demo

Verify the proxy path

Before running the demo, make sure the client is connecting to the OhMyDB listening port rather than directly to the database backend.

Typical local setup:

PostgreSQL backend: 5432
OhMyDB proxy:       5433

A client connection to port 5433 confirms traffic is passing through OhMyDB before reaching PostgreSQL.

Run a normal query

SELECT id, name, status
FROM demo_customers
ORDER BY id;

Try a dangerous mutation

UPDATE demo_customers
SET status = 'inactive';

Because the UPDATE has no WHERE clause, OhMyDB evaluates it as a potentially full-table mutation and applies the configured safety policy before execution.

Expected blocked-query output

For an UPDATE without a WHERE clause, the client should receive a blocked-query response describing the policy decision.

Typical result:

Query blocked by OhMyDB
Severity: CRITICAL
Operation: UPDATE

The exact wording may vary with configuration, but the mutation should not reach the backend when the active policy blocks it.

Verify the database

SELECT COUNT(*) AS inactive_customers
FROM demo_customers
WHERE status = 'inactive';

When the mutation is blocked, the result remains:

inactive_customers
------------------
0

Reset the demo data

To repeat the walkthrough, reset the demo rows before running the risky mutation again:

UPDATE demo_customers
SET status = 'active';

Verify the reset:

SELECT id, name, status
FROM demo_customers
ORDER BY id;

This keeps repeated local demonstrations deterministic and avoids carrying state from an earlier run.

Safety model

OhMyDB can apply:

ALLOW
CONFIRM
BLOCK

The project follows a fail-closed approach for malformed, ambiguous, unsupported, or otherwise unsafe database behavior.

For full configuration and supported protocol details, see the main README.