AnovaCloud Labs

We experiment in the open.

Labs is where we prototype tooling against real problems — config checkers, migration analyzers, health-check scripts. Everything here is labeled for what it is: beta, in progress, or a note. Nothing is faked as finished, and nothing here is a sales pitch.

Beta — working prototype, usable now In progress — being built, not ready Open-source starter — repo ready, not yet published Backlog — planned, not started

01 — Experiments

On the bench right now.

Beta experiment-001

PostgreSQL Config Sanity Checker

Paste your postgresql.conf (or SHOW ALL output) and get a heuristic review: memory sizing vs RAM, connection risk, checkpoint and autovacuum settings, durability flags. This is a real working tool — it runs entirely in your browser, nothing leaves this page.

Paste postgresql.conf contents

Server RAM (GB, optional):

Heuristics, not a diagnosis — a real health check looks at workload, stats views, and query plans too.
Bare numbers follow PostgreSQL conventions (8kB blocks for shared_buffers, kB for work_mem).
Strip secrets before pasting. The tool never sends data anywhere — but your clipboard history might.

In progress experiment-002

SQL → PostgreSQL migration analyzer

Upload SQL Server or Oracle DDL and get an incompatibility report: data-type mappings, procedural code hotspots (T-SQL / PL/SQL), and a rough effort estimate per object.

Status: being built — not ready to use. The parser handles CREATE TABLE today; procedural code analysis is next. Planned as an open-source release when it earns the label.

Want it sooner? Tell an architect — real migration work funds the lab.

Open-source starter repo-ready, not yet published

pg-health-check

A Python script (stdlib only, plus an optional psycopg driver) that runs 20 read-only PostgreSQL health checks — bloat estimate, unused indexes, cache hit ratios, connection pressure, long-running queries, replication lag, autovacuum status, table sizes — and writes a Markdown report.

pg_health_check.py — argparse CLI (--dsn, --format md, --dry-run)
README.md — purpose, usage, sample output, safety notes
LICENSE — MIT, © AnovaCloud
.github/workflows/ci.yml — syntax check + dry run

Repo-ready in our workspace — GitHub publication pending. Ask an architect and we'll send you the repo.

Backlog planned, not started

Connection-string parser

Planned: paste a JDBC / ADO.NET / libpq connection string, get the parsed host, port, database, and SSL mode — plus a redaction mode that strips credentials before you share it in a ticket. Not started yet.

02 — Lab notes

Short notes from the bench.

Not whitepapers — working notes we'd hand a colleague.

Lab note · PostgreSQL

Start every Postgres health check with pg_stat_statements

Slow-query logs tell you what was slow. pg_stat_statements tells you what's expensive — normalized query text with total time, calls, and mean latency, so the top 5 rows are your optimization backlog, ranked.

Enable it: add to shared_preload_libraries, restart, CREATE EXTENSION pg_stat_statements;. Then:

SELECT query, calls, round(total_exec_time::numeric,1) AS total_ms
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;

Caveat: stats accumulate since the last reset — pg_stat_statements_reset() after a deploy before you compare.

Lab note · Agentic AI

Evals before agents: the cheapest reliability win

Before deploying any agent, build a 50-case eval set: realistic inputs, expected tool calls, expected outcomes. Score task success and tool-call correctness. Re-run it on every prompt or model change.

Teams that skip this discover regressions from users. Teams that do it catch the "helpful" model update that silently changed the tool-call format — in CI, not in production.

Our rule of thumb: if you can't write 50 eval cases, you don't understand the task well enough to automate it yet.

Have a problem the lab should chew on?

Real client work funds the experiments. Tell us what's hard.

Talk to an Architect Start a Project