Labs
Labs are my test bench: small, reproducible environments where I combine AI, automation and databases to see what really holds up, before thinking about production. Every lab is published on GitHub with the code and the instructions to rebuild it.
LAB 01
AI triage of PostgreSQL locks
The AI proposes, a human signs off, the database keeps the record. Every 5 minutes a workflow looks for locks on PostgreSQL, retrieves the severity criteria from the vector DB, has a local model assess them and sends the proposal to Telegram, where a person approves or rejects it.
The controls live in the database, not in the workflow: even a faulty workflow cannot do more than the roles allow.
Components
- PostgreSQL + pgvectorThe monitored database, the vector DB with the severity criteria, and the action log
- OllamaLocal models: llama3.2:3b for the assessment, nomic-embed-text for embeddings
- n8nThe workflow that detects locks, queries the model and handles the approval
- TelegramThe channel where a person approves or rejects the proposal
- Docker ComposeThe whole environment starts with a single command
Tested features
- The monitoring role sees sessions and locks but changes nothing
- The action role can only call the approved function
- Without a person's sign-off the action is rejected
- Superusers and AI roles cannot be terminated
- Every run, even a failed one, ends up in the log
- The log cannot be changed or deleted, not even by a superuser
- P1-P4 severity comes from thresholds stored in the vector DB
- Query timeouts for the AI roles: 5 and 10 seconds
LAB 02
Real-time dashboards with Apache Fluss and Flink
Flink does the maths, once per order. The dashboard reads a copy. Every dashboard refreshing every few seconds is a query against the production database: here orders land in Fluss, Flink updates the totals in streaming and copies them to PostgreSQL, and Superset shows them a few seconds later.
In the lab Flink generates the orders; in a real setup they would arrive through CDC from the transaction log, without querying the production tables. All the main components are open source.
Components
- Apache FlussStreaming storage: primary-key tables that produce their own changelog
- Apache Flink + SQL GatewayStreaming jobs that update per-customer totals and copy the data to PostgreSQL
- PostgreSQLThe copy queried by the dashboard, separate from the source
- Apache SupersetDashboard refreshing automatically every 10 seconds
- ZooKeeper and RustFSFluss cluster metadata and S3 storage for older data
- n8nTest workflow that writes and reads through the SQL Gateway, for prototyping only
- Docker ComposeThe whole environment starts with a single script
Tested features
- Per-customer totals update on every order, without recomputing the table
- The PostgreSQL copy stays consistent: the number of orders matches the sum of the totals
- Superset charts read from the copy only
- The dashboard refreshes by itself every 10 seconds
- The n8n workflow inserts orders and reads the totals computed by Flink
- Data and metadata survive stop and restart
- On restart the jobs start again and recompute the totals from the data stored in Fluss
- Apache 2.0 license