Efficient by Architecture

Projection tables shift work from runtime to precomputation. Web requests consume minimal CPU. One server does the work of several.

Lower hosting footprint, reduced infrastructure, vertical-scaling-first design.

The Technical Case

⚡

Precomputation Over Runtime

Projection tables store pre-composed JSONB. Reads are a single SELECT—no JOINs, no complex query planning at request time.

🧠

Lower RAM Footprint

No ORM object hydration. No DataLoader caching layers. Data flows directly from PostgreSQL to HTTP response.

🦀

Lightweight Rust Adapter

Rust performs field selection and camelCasing. No Python in the read hot path. Predictable, memory-efficient I/O.

Why This Matters for Efficiency

Traditional ORM Stack

  • 1. SQL query with JOINs (CPU: significant)
  • 2. ORM hydrates objects (RAM: significant)
  • 3. Serializer transforms to JSON (CPU: moderate)
  • 4. DataLoader batches N+1 queries (CPU: varies)
  • 5. Python GC cleans up objects (CPU: moderate)

Multiple steps, memory churn

FraiseQL Stack

  • 1. Single SELECT from projection table (CPU: minimal)
  • 2. Rust extracts requested fields (CPU: minimal)
  • 3. Stream to HTTP response (RAM: minimal)
  • 4. No DataLoader needed
  • 5. No object cleanup needed

Fewer steps, minimal memory allocation

The Business Case

Run on Smaller Hardware

Architecture-based estimates suggest FraiseQL can handle ~4× more logical ops per vCPU compared to typical ORM-based GraphQL stacks.

Metric Traditional FraiseQL
Read QPS / vCPU ~140 ~571
Write QPS / vCPU ~40 ~160
16-vCPU mixed ops/s ~1,300 ~6,000

Architecture-based projections. Validate with your benchmarks.

Lower Infrastructure Costs

Smaller servers, fewer services, and reduced operational complexity translate to lower cloud spend.

Compute efficiency ~4× more ops/vCPU
Redis/cache services Often eliminated
Operational complexity Reduced
Expected savings Varies by workload

The trade-off: FraiseQL uses 2-4× more storage for projection tables (typical SaaS schemas). At ~$0.10/GB/month, 4× growth on 100GB adds $30/month— offset by running smaller servers. Projection tables don't need separate backups as they can be rebuilt.

Economics Deep Dive

Monthly Cost Comparison: 1M Requests/Day

100GB base data, typical SaaS API workload

Cost Component Traditional Stack FraiseQL Difference
Compute
API servers 		4× m5.large
$280/mo 		1× m5.large
$70/mo 		-$210
Database
PostgreSQL RDS 		db.r5.large
$175/mo 		db.r5.large
$175/mo 		$0
Storage
gp3 SSD @ $0.10/GB 		100GB
$10/mo 		500GB (5×)
$50/mo 		+$40
Cache Layer
Redis/ElastiCache 		cache.r5.large
$110/mo 		Not needed
$0/mo 		-$110
TOTAL $575/mo $295/mo -$280/mo
(-49%)

Monthly Cost vs Request Volume

$0 $500 $1K $1.5K $2K 100K 500K 1M 5M 10M Requests/Day Monthly Cost Traditional FraiseQL

The gap widens as scale increases—FraiseQL's efficiency compounds.

Storage vs Compute Trade-off

Traditional Compute $280 Cache $110 FraiseQL Compute $70 Storage $50 $575/mo $295/mo Compute Cache Storage

Higher storage cost is dwarfed by compute and cache savings.

When Does FraiseQL Make Sense?

✅

Strong Fit

Read/write ratio >10:1

  • • Public APIs
  • • Content platforms
  • • E-commerce catalogs
  • • Dashboard backends

Savings: 40-60%

⚖️

Evaluate

Read/write ratio 3:1 to 10:1

  • • Internal tools
  • • B2B applications
  • • Moderate-traffic APIs
  • • Mixed workloads

Savings: 10-40%

❌

Not Recommended

Read/write ratio <3:1

  • • IoT ingestion
  • • Logging systems
  • • Write-heavy analytics
  • • Event streaming

May cost more

Quick Calculator

Your reads/day: R
Your writes/day: W
Ratio (R/W): >10 = strong fit
Rule of thumb: 10× more reads = 50% savings

Annual Impact at Scale

Small Startup

100K req/day

$1,200

saved/year

Growing SaaS

1M req/day

$3,400

saved/year

Mid-Market

10M req/day

$24,000

saved/year

Enterprise

100M req/day

$180,000+

saved/year

Estimates based on AWS pricing, read-heavy workloads (90% reads), 5× storage multiplier. Your results will vary based on workload characteristics.

The Environmental Case

Efficiency Reduces Energy Consumption

Data centers consume ~1% of global electricity. Fewer CPU cycles per request, fewer services running, and smaller servers all contribute to reduced energy consumption.

🌱

~4×

more ops per vCPU (expected)

🔌

Fewer

services to operate

🌍

Proportional

energy reduction

How FraiseQL Reduces Energy Consumption

1

Pre-computation over runtime computation

Projection tables shift work from runtime CPU to occasional precomputation. Web requests consume minimal energy, especially at scale.

2

Lightweight Rust adapter

The read hot path runs in Rust—field selection, camelCasing, streaming. No Python, no ORM, no object hydration. More efficient execution.

3

No garbage collection pressure

No ORM objects to create and destroy. No DataLoader caches to manage. Less memory churn means less CPU spent on GC.

4

Reduced infrastructure

One PostgreSQL instance often replaces Redis and external caches. Fewer services = less energy, simpler operations.

Run on Modest Hardware

Production-Ready on

  • ✓ 2-core VPS ($10-20/month)
  • ✓ Raspberry Pi 4 (4GB RAM)
  • ✓ ARM instances (Graviton, M1)
  • ✓ Shared hosting with PostgreSQL

Why This Matters

  • 🌍 Democratizes high-performance APIs for small teams and budgets
  • 💚 Lower barrier to entry for sustainable software
  • 🔋 Run in low-power environments (edge, IoT)

Build Efficient APIs

Performance and sustainability are not trade-offs. FraiseQL delivers both.

Get Started