How Vela Works

Key concepts

The mental model behind Vela: branch data like code, point-in-time bookmarks for safety, and stateless compute attached to fast shared storage. These principles make environments instant, portable, and affordable.

Copy-on-Write Branches

Create isolated branches in seconds. Data blocks are shared until changed, so large databases clone instantly and cheaply.

Bookmarks & Time Travel

Capture consistent points in time for audits, disaster recovery, and safe rollbacks. Treat data history like a Git graph.

Scale to Zero

Suspend idle compute automatically to cut costs to near-zero while storage remains durable and ready to resume instantly.

Storage/Compute Separation

Compute instances are stateless. Fast, durable NVMe-backed storage serves multiple branches with high throughput.

RBAC & IAM

Postgres roles plus platform-level access control. Integrate with SSO providers and enforce least privilege across teams.

Plain PostgreSQL

100% PostgreSQL compatibility. Standard drivers and SQL. Bring your favorite extensions and tools.

What is Vela

Vela is a PostgreSQL platform with a BaaS experience: instant provisioning, self-service branches, safe rollbacks, and observability out of the box. Unlike black-box serverless databases, Vela uses plain Postgres so you keep portability and control.

Developer-first console, CLI, and API
Works with existing Postgres drivers and ORMs
Designed for BYOC and on-prem deployments

Core capabilities

Instant copy-on-write branching with per-branch policies and quotas
Bookmarks with metadata for compliance, audits, and reproducibility
Usage metering and cost controls per project, branch, and team

Kubernetes-native runtime

Compute runs in containers or KubeVirt-powered VMs, orchestrated by Kubernetes for scheduling, isolation, and automation. Storage is provided by a high-performance, NVMe-backed distributed layer.

Multi-tenant isolation

HA & backups

Observability

Policy & quotas

Deployment options

AWS BYOC

GCP BYOC

Azure BYOC

Bare metal

Air‑gapped

Why use Vela

Faster teams

Spin up production-like environments per feature. Ship confidently with real data and isolated changes.

Right-sized costs

Scale compute up or down per branch and suspend idle environments automatically.

Enterprise controls

RBAC, audit trails, and strict isolation. Keep compliance while developers move fast.

Lower-risk releases

Bookmark and branch around every release to ensure instant rollback and precise forensics.

Portable & OSS-aligned

Plain PostgreSQL means standard SQL, drivers, and extensions—no lock‑in.

Unified workloads

Run OLTP, analytics, vector, and time‑series together with predictable performance.

Why shared staging slows teams down — and how Vela’s branches fix it.

Postgres Branching / Cloning

Create independent branches from any point in time. Branches inherit data blocks and diverge on write, so even multi‑TB databases clone instantly. Each branch has its own connection string and resource policy.

How it works

Copy‑on‑write: unchanged blocks are shared across branches; modified blocks are written once.
Per-branch limits: vCPU, RAM, and IOPS can be set independently.
Branch merges are performed using SQL or migration tools against the parent.

Typical workflow

Create a branch from production or a bookmark.
Run tests and apply schema changes safely.
Promote or discard; only changed data incurred extra storage.

Demonstration of branching and clone workflows.

Copy-on-Write Snapshots

Copy-on-write snapshots are the foundation of Vela's branching and cloning. When you create a snapshot, Vela captures the current state of your database without copying data. Branches reference shared data blocks until they diverge, enabling instant clones of even multi-terabyte databases.

How snapshots work

Snapshots are immutable, consistent points in time of your entire database.
Branches created from snapshots share underlying data blocks until writes occur.
Only modified blocks are written separately, keeping storage efficient.
Multiple branches can coexist without duplicating unchanged data.

Benefits

Instant cloning: Create branches in seconds regardless of database size.
Cost efficiency: Storage scales with actual changes, not branch count.
Safe experimentation: Modify data in branches without affecting the parent.
Quick rollback: Discard branches instantly without cleanup overhead.

How copy-on-write snapshots enable efficient database branching and cloning.

Common use cases

CI/CD testing

Create a fresh snapshot for each test run. Branches isolate schema changes and data mutations without interfering with other pipelines.

Feature development

Branch from production to develop and test new features on real data. Merge changes back safely or discard them instantly.

Production troubleshooting

Create a snapshot before applying a fix. If the fix fails, restore the snapshot or branch from it to investigate without downtime.

Data analytics

Snapshot production at a point in time, then analyze without impacting live workloads or copying terabytes of data.

Postgres Time Travel

Bookmarks capture consistent snapshots you can return to at any time. Use them to protect releases, run historical analyses, or recreate incidents exactly as they happened.

Bookmarks

Immutable reference points with metadata for audit and compliance.

Checkout

Attach any bookmark to a compute environment to reproduce a state precisely.

Branch from history

Create branches from the past for safe fixes, tests, and investigations.

Workflows

Create bookmarks before risky migrations or releases.
Checkout an older bookmark to reproduce and debug issues.
Branch from a bookmark to test hotfixes without touching prod.

Best practices

Name bookmarks consistently and include context in descriptions.
Keep sensitive data policies consistent across branches.
Restrict destructive operations via RBAC and approvals.

Postgres Scale to Zero

Idle environments are automatically suspended to eliminate compute waste. When accessed, they resume quickly with warm caches and preserved storage state.

Policies

Configure automatic suspension windows per project or branch. Resume on connect via console, CLI, or API.

Cost & performance

Reduce spend for dev/test while keeping near‑instant wake‑ups optimized for low latency.

Policy examples

Dev branches suspend after 30 minutes of inactivity.
QA suspends outside 08:00–20:00 local time.
Prod never suspends; burst scaling only.

Resume triggers

First incoming connection on the branch DSN.
Manual resume via console, CLI, or API.
Scheduled jobs (cron) before test runs.

Separation of Storage and Compute

Vela decouples compute from storage so you can right-size CPUs and memory without copying data. Shared NVMe-backed storage feeds multiple compute nodes with high throughput and low latency.

Benefits

Independent scaling of compute and storage for cost efficiency.
High cache hit rates and low-latency I/O on NVMe-backed media.
No expensive EBS/IOPS throttling or snapshot copies.

Operational controls

Live migration of projects across nodes for maintenance.
Per-branch resource limits and auto-scaling policies.
Observability for CPU, memory, I/O, and storage footprint.

Overview of storage/compute separation and performance benefits.

Why NVMe Storage Matters for Database Performance

Explore how Vela's NVMe-based distributed storage delivers consistently low latency without the limitations of traditional cloud storage solutions.

Storage I/O Performance Comparison

💾 Real-time I/O operations visualization

Each ball represents a database read/write operation. Faster movement = lower latency = better performance for your applications.

CPU ↔ Vela (NVMe)

Local NVMe with simplyblock

~150µs

1M+ IOPS

💾

I/O Op

CPU ↔ EBS io2 (Express)

Premium network storage

~500µs

64K IOPS (provisioned)

💾

I/O Op

CPU ↔ EBS GP3

Standard cloud block storage

~2ms

3K-16K IOPS (burstable)

💾

I/O Op

CPU ↔ S3

Object storage API calls

~10ms

3.5K requests/sec

💾

I/O Op

What you're seeing:

• Vela (distributed NVMe) Blazing fast I/O operations - 150µs local storage latency
• Express Network Storage: Decently fast I/O but very expensive (prohibitive extra cost for provisioned IOPS)
• Network Storage: Slower round trips - millisecond network overhead
• S3: Much slower - API call and object storage latency

Vela's Distributed NVMe Architecture

Why Vela Outperforms Both Local NVMe and Cloud Storage

vs. Local NVMe: Vela provides the speed of local NVMe PLUS distributed durability, automatic failover, and elastic scaling without single points of failure.

vs. Cloud Storage: Eliminates network latency, IOPS throttling, and unpredictable performance while maintaining enterprise-grade reliability.

Node 1

Node 2

Node 3

Node 4

🚀 Vela's Distributed Advantage

• Parallel processing across nodes
• No single point of failure
• Automatic load balancing
• Consistent performance at scale

⚡ Performance Benefits

• 1M+ IOPS sustained
• Sub-millisecond latency
• Linear scaling
• No IOPS throttling

⚠️ Traditional Limitations

• Sequential processing
• Single node bottlenecks
• Manual scaling required
• Performance degradation

IOPS Performance: The Vela Advantage

Understanding IOPS Impact on Database Performance

IOPS (Input/Output Operations Per Second) directly affects database query speed, transaction throughput, and user experience. Higher consistent IOPS means faster data retrieval and better application responsiveness.

Real Impact: A single complex query might require 10K+ IOPS. Cloud throttling can slow this by 10-100x.

Cost Factor: Provisioned IOPS in cloud can cost $1000s/month for enterprise workloads.

🌩️ Cloud EBS (GP3)

3K-16K

IOPS (burstable)

⚠️ Credits drain during high load

📈 Latency spikes when throttled

🔄 Unpredictable performance

💰 Extra cost for consistent performance

💸 Cloud EBS (io2)

64K

IOPS (provisioned)

💰 $0.125/IOPS/month (expensive)

🌐 Network latency overhead

🔧 Complex provisioning

📉 Fixed capacity, no elasticity

🚀 Vela (Distributed NVMe)

1M+

IOPS (consistent)

✅ No artificial limits

⚡ Hardware-native performance

📈 Linear scaling with nodes

💰 Cost-effective at scale

Real-World PostgreSQL Impact

OLTP Workloads: E-commerce, SaaS apps need 50K+ IOPS for peak traffic
Analytics: Data warehouses require burst capacity to 100K+ IOPS
Mixed Workloads: Modern apps need consistent high IOPS for both reads and writes
Backup/Restore: Operations can consume entire IOPS allocation

Vela's Distributed Advantage

No Throttling: Consistent 1M+ IOPS without burst credits
Auto-Scaling: Performance scales with cluster size automatically
Cost Efficiency: No per-IOPS charges, predictable pricing
Durability: Distributed replication without performance penalty

Vela's Performance Advantage

By running Postgres on local NVMe through simplyblock's software-defined storage, Vela eliminates the unpredictable latency spikes and IOPS limitations of traditional cloud storage while maintaining enterprise-grade durability and safety.

Slash Compute Costs with Right-Sized Resources

Vela eliminates overprovisioning and waste by enabling fine-grained scaling, metering real usage, and minimizing idle workloads. Pay for what you actually use, not what you provision.

Right-Sized Resources per Project

Unlike fixed VM/database hosting, Vela lets teams independently scale vCPU, RAM, IOPS, and storage. Avoid overprovisioning—give QA or staging clones just the minimal compute they need.

Traditional: Pay for full prod-sized replicas across all environments
Vela: Right-size each clone to its actual requirements

Pay for Actual Usage

Vela continuously meters both provisioned and consumed compute (CPU seconds, RAM usage, I/O) per project. Enable chargeback and optimization by downsizing or pausing idle environments.

Benefit: Teams can reduce wasted spend by 60-80% through intelligent resource management

Instant Resizing

Compute resources can be resized online (IOPS, vCPU) or with minimal interruption (RAM). Dynamic scaling means you avoid paying for peak usage 24/7.

Live Migration for Efficiency

Projects can be live-migrated across nodes without downtime. Higher cluster utilization means fewer servers required and lower total infrastructure costs.

Stop/Start & Cloning Efficiency

Developers can spin up and shut down clones instantly. Compute is only consumed while tests run, unlike traditional staging servers that sit idle but cost money.

Key concepts

Copy-on-Write Branches

Bookmarks & Time Travel

Scale to Zero

Storage/Compute Separation

RBAC & IAM

Plain PostgreSQL

What is Vela

Core capabilities

Deployment options

Why use Vela

Postgres Branching / Cloning

How it works

Typical workflow

Copy-on-Write Snapshots

How snapshots work

Benefits

Common use cases

CI/CD testing

Feature development

Production troubleshooting

Data analytics

Postgres Time Travel

Bookmarks

Checkout

Branch from history

Workflows

Best practices

Postgres Scale to Zero

Policies

Cost & performance

Policy examples

Resume triggers

Separation of Storage and Compute

Benefits

Operational controls

Why NVMe Storage Matters for Database Performance

Storage I/O Performance Comparison

What you're seeing:

Vela's Distributed NVMe Architecture

Why Vela Outperforms Both Local NVMe and Cloud Storage

IOPS Performance: The Vela Advantage

Understanding IOPS Impact on Database Performance

🌩️ Cloud EBS (GP3)

💸 Cloud EBS (io2)

🚀 Vela (Distributed NVMe)

Real-World PostgreSQL Impact

Vela's Distributed Advantage

Vela's Performance Advantage

Slash Compute Costs with Right-Sized Resources

Right-Sized Resources per Project

Pay for Actual Usage

Instant Resizing

Live Migration for Efficiency

Stop/Start & Cloning Efficiency

Try Vela with your own workloads