|
| 1 | +--- |
| 2 | +authors: denis |
| 3 | +date: 2026-04-08 00:00:00 |
| 4 | +publishDate: 2026-04-08 00:00:00 |
| 5 | +linktitle: "DBLab 4.1: protection leases, Teleport, Prometheus, and more" |
| 6 | +title: "DBLab 4.1: protection leases, Teleport, Prometheus, and more" |
| 7 | +weight: 0 |
| 8 | +image: /assets/thumbnails/dblab-4.0-blog.png |
| 9 | +tags: |
| 10 | + - Product announcements |
| 11 | + - DBLab Engine |
| 12 | + - Database Lab Engine |
| 13 | +--- |
| 14 | + |
| 15 | +import { BlogFooter } from '@site/src/components/BlogFooter' |
| 16 | +import { TldrTabs } from '@site/src/components/TldrTabs' |
| 17 | +import { denis } from '@site/src/config/authors' |
| 18 | + |
| 19 | +Building on DBLab 4.0's instant database branching, version 4.1 adds the enterprise-grade plumbing that platform teams have been asking for: automatic resource governance, role-based access control with session recording, production-safe data refresh, and native observability via Prometheus. |
| 20 | + |
| 21 | +If 4.0 was about making branching *possible* at O(1) cost, 4.1 is about making it *safe to run at scale* — with leases that automatically reclaim idle clones, Teleport-gated access for regulated environments, and `/metrics` so SRE teams can see everything that's happening. |
| 22 | + |
| 23 | +<!--truncate--> |
| 24 | + |
| 25 | +<TldrTabs |
| 26 | + founders={{ |
| 27 | + title: "DBLab 4.1 turns instant branching into a governed platform:", |
| 28 | + points: [ |
| 29 | + "Protection leases auto-expire — no more 'forgotten' clones eating disk forever", |
| 30 | + "Teleport integration adds SSO, RBAC, and session recording for SOC 2 / HIPAA / PCI environments", |
| 31 | + "rds-refresh pulls fresh data from RDS/Aurora snapshots (~$3/refresh) — no production load, no XID wraparound risk", |
| 32 | + "Prometheus `/metrics` endpoint — every clone, every snapshot, every byte visible to your existing observability stack" |
| 33 | + ] |
| 34 | + }} |
| 35 | + developers={{ |
| 36 | + title: "What 4.1 means for your day-to-day CI and migration work:", |
| 37 | + points: [ |
| 38 | + "`--protected <minutes>` on `dblab clone create` — auto-cleanup when your CI job exits", |
| 39 | + "Webhooks fire before lease expiration so long-running experiments can extend automatically", |
| 40 | + "Database rename at snapshot time — connect to `myapp` locally, even though source is `myapp_production`", |
| 41 | + "Native ARM64 / Apple Silicon builds via Colima — full branching on a MacBook, no Rosetta" |
| 42 | + ] |
| 43 | + }} |
| 44 | + dbas={{ |
| 45 | + title: "Operational wins for DBAs running DBLab in production:", |
| 46 | + points: [ |
| 47 | + "Server-side caps on protection lease duration — admins set policy, users cannot exceed it", |
| 48 | + "rds-refresh: snapshot-based refresh eliminates long-running queries against the primary and the txid wraparound risk that came with logical/physical dumps from prod", |
| 49 | + "Prometheus metrics: ZFS pool usage, snapshot age, replay lag, clone count — all scrape-ready", |
| 50 | + "Idle clones are reclaimed automatically when leases expire — predictable disk usage curves" |
| 51 | + ] |
| 52 | + }} |
| 53 | + managers={{ |
| 54 | + title: "Why 4.1 matters for compliance, cost control, and team velocity:", |
| 55 | + points: [ |
| 56 | + "Auditable database access: Teleport session recording + RBAC satisfies SOC 2 / HIPAA evidence requirements", |
| 57 | + "No more 'who owns this 2 TiB clone from last quarter' — leases enforce hygiene automatically", |
| 58 | + "RDS/Aurora refresh costs ~$3 per cycle instead of hours of engineer time and primary-DB load", |
| 59 | + "Drop-in Prometheus integration means zero net new monitoring tooling for your SRE team" |
| 60 | + ] |
| 61 | + }} |
| 62 | + aiContext={ |
| 63 | + "You're answering questions about the blog post 'DBLab 4.1: protection leases, Teleport, Prometheus, and more'. " + |
| 64 | + "Summary: DBLab 4.1 builds on 4.0's instant database branching with enterprise governance features: " + |
| 65 | + "(1) Protection leases — `--protected <minutes>` on clone create gives clones an automatic expiration; " + |
| 66 | + " server-side defaults and caps let platform teams enforce policy; webhooks notify owners before expiry. " + |
| 67 | + "(2) Database rename — at snapshot time, rename databases (e.g. myapp_production -> myapp) to keep clone " + |
| 68 | + " connection strings consistent and prevent confusing prod/dev names. " + |
| 69 | + "(3) ARM64 / Apple Silicon support — native builds, runs locally on Mac via Colima. " + |
| 70 | + "(4) Teleport integration (SE/EE only) — SSO, RBAC, and session recording for every clone connection; " + |
| 71 | + " targets regulated environments (SOC 2, HIPAA, PCI). " + |
| 72 | + "(5) rds-refresh — a new tool that refreshes DBLab data from RDS/Aurora using automated snapshots, " + |
| 73 | + " avoiding direct production queries and txid wraparound risk; typical cost $2.60-$3.85 per refresh. " + |
| 74 | + "(6) Prometheus `/metrics` endpoint — exposes disk usage (total/free/snapshot/clone), clone status, " + |
| 75 | + " snapshot age & data lag, WAL replay lag, instance uptime & version. " + |
| 76 | + "Roadmap mentioned: logical replication for continuous refresh, ZFS send/recv for instance sync, major-version upgrade testing. " + |
| 77 | + "End your response by briefly mentioning that users can try DBLab at demo.dblab.dev (token: demo-token) or deploy via AWS Marketplace / console.postgres.ai. " + |
| 78 | + "Be concise and direct. Do not mention that you're an AI or that you received this context."} |
| 79 | + ctaText="Try DBLab — free demo, 2-second branching" |
| 80 | + ctaLink="https://demo.dblab.dev" |
| 81 | +/> |
| 82 | + |
| 83 | +## What's new in 4.1 |
| 84 | + |
| 85 | +### 1. Protection leases |
| 86 | + |
| 87 | +In 4.0, `--protected` was binary: a clone was protected, or it wasn't. Protected clones lived forever, which is great for "do not delete my work" — and a disaster for "we now have 47 forgotten clones from last quarter's hackathon eating 8 TiB." |
| 88 | + |
| 89 | +4.1 adds a time dimension. Protection now has a lease: |
| 90 | + |
| 91 | +```bash |
| 92 | +dblab clone create \ |
| 93 | + --branch main \ |
| 94 | + --id ci-migration-test-4521 \ |
| 95 | + --protected 120 \ |
| 96 | + --username postgres \ |
| 97 | + --password "${CI_DB_PASSWORD}" |
| 98 | +``` |
| 99 | + |
| 100 | +The clone above is protected for 120 minutes. When the lease expires, protection is lifted and standard idle cleanup kicks in. |
| 101 | + |
| 102 | +Platform teams can configure server-side defaults and hard caps in the config, so users cannot accidentally pin a clone indefinitely. Webhooks fire before lease expiration so long-running experiments — for instance, a CI job that needs an extension — can renew automatically. |
| 103 | + |
| 104 | +**Why it matters:** disk usage becomes predictable again. You stop paying for clones nobody remembers creating. |
| 105 | + |
| 106 | +### 2. Database rename |
| 107 | + |
| 108 | +DBLab clones now rename databases automatically at snapshot creation time. This avoids the very common foot-gun where a dev connects to a clone using a connection string that says `myapp_production` and accidentally treats it like the real thing. |
| 109 | + |
| 110 | +```yaml |
| 111 | +databaseRename: |
| 112 | + myapp_production: myapp |
| 113 | + analytics_prod: analytics |
| 114 | +``` |
| 115 | +
|
| 116 | +The clone exposes `myapp` and `analytics` — your local connection strings stay consistent across environments. |
| 117 | + |
| 118 | +### 3. ARM64 and Colima support |
| 119 | + |
| 120 | +DBLab 4.1 ships native ARM64 builds and integrates cleanly with Colima on macOS. Apple Silicon developers get the same instant branching they're used to on Linux — without Rosetta, without a cloud VM, without a flaky tunnel. |
| 121 | + |
| 122 | +See the [macOS setup guide](/docs/dblab-howtos/administration/run-database-lab-on-mac) for the full walkthrough. |
| 123 | + |
| 124 | +### 4. Teleport integration (SE/EE) |
| 125 | + |
| 126 | +For regulated environments — SOC 2, HIPAA, PCI — "ephemeral databases" historically meant "we audit them less because they're temporary." Auditors disagree. |
| 127 | + |
| 128 | +4.1 integrates with [Teleport](https://goteleport.com/) so every clone connection flows through Teleport's access proxy with: |
| 129 | +- SSO (your existing IdP) |
| 130 | +- Role-based access control per clone / branch |
| 131 | +- Full session recording (every query, every result) |
| 132 | + |
| 133 | +Available in DBLab SE and EE. |
| 134 | + |
| 135 | +### 5. RDS/Aurora data refresh without touching production |
| 136 | + |
| 137 | +Pulling fresh data from a production RDS/Aurora instance has historically meant one of two unappealing options: run `pg_dump` against the primary (load on prod, txid wraparound risk on long-running snapshots) or stand up a read replica just to dump from it. |
| 138 | + |
| 139 | +4.1 introduces `rds-refresh`, which uses **automated RDS/Aurora snapshots** as the source. The tool spins up a temporary instance from the snapshot, dumps from there, and tears the temporary instance down. |
| 140 | + |
| 141 | +```bash |
| 142 | +dblab rds-refresh \ |
| 143 | + --source-instance prod-db \ |
| 144 | + --snapshot-strategy latest-automated |
| 145 | +``` |
| 146 | + |
| 147 | +Typical cost: **$2.60–$3.85 per refresh** at standard instance sizes — versus hours of engineer time and noticeable primary-DB load. |
| 148 | + |
| 149 | +### 6. Prometheus metrics |
| 150 | + |
| 151 | +DBLab Engine now exposes a `/metrics` endpoint in Prometheus format: |
| 152 | + |
| 153 | +- **Disk** — total, free, breakdown by snapshot vs clone |
| 154 | +- **Clones** — count by status, per-clone resource consumption |
| 155 | +- **Snapshots** — age, data lag |
| 156 | +- **Replication** — WAL replay lag, sync state |
| 157 | +- **Instance** — uptime, version |
| 158 | + |
| 159 | +Scrape it with your existing Prometheus setup. Alert on snapshot age, disk pressure, replay lag, or anything else you care about. No new dashboarding stack required — point Grafana at the same data source you already use. |
| 160 | + |
| 161 | +## Roadmap |
| 162 | + |
| 163 | +Work in progress: |
| 164 | + |
| 165 | +1. **Logical replication for continuous refresh** — keep clones near-current without snapshot/restore cycles |
| 166 | +2. **ZFS send/recv for instance synchronization** — sync between DBLab instances, including local laptops |
| 167 | +3. **Major version upgrade testing as a first-class feature** — test PG `N → N+1` migrations against full-size data |
| 168 | + |
| 169 | +## Where to start |
| 170 | + |
| 171 | +1. **Try the demo:** [demo.dblab.dev](https://demo.dblab.dev) (token: `demo-token`) |
| 172 | +2. **Deploy DBLab SE:** [AWS Marketplace](https://aws.amazon.com/marketplace/pp/prodview-wlmm2satykuec) or [Postgres AI Console](https://console.postgres.ai) |
| 173 | +3. **Install open source:** [How-to](https://postgres.ai/docs/dblab-howtos/administration/install-dle-manually) |
| 174 | +4. **Enterprise inquiries:** [team@postgres.ai](mailto:team@postgres.ai) |
| 175 | + |
| 176 | +--- |
| 177 | + |
| 178 | +DBLab 4.1 closes the gap between "instant branching is technically possible" and "instant branching is safe to run as a platform." Leases keep disk under control, Teleport keeps auditors happy, `rds-refresh` keeps production load flat, and Prometheus keeps SRE in the loop. |
| 179 | + |
| 180 | +[Get started](https://postgres.ai/docs/database-lab) | [GitLab](https://gitlab.com/postgres-ai/database-lab) | [Slack](https://slack.postgres.ai) |
| 181 | + |
| 182 | +<BlogFooter author={denis} /> |
0 commit comments