# DharmOps

> DharmOps is a data infrastructure consulting firm. We help engineering teams manage databases on retainer (managed DBA), cut cloud database bills 30–40%, build AI features on pgvector, design Redis caching layers, implement dbt pipelines, and fix N+1 query performance issues. Hands-on, cross-platform database expertise. Free diagnostic.

DharmOps brings hands-on, cross-platform database expertise — PostgreSQL, MySQL, Oracle, SQL Server, and major cloud platforms. We work with engineering teams at SaaS companies, fintechs, e-commerce businesses, and enterprises across AWS, GCP, and Azure. We support PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Redis, AWS RDS, Aurora, Google Cloud SQL, and Azure SQL Database. Every engagement starts with a free 30-minute diagnostic — no pitch, just an honest assessment of your situation.

Contact: contact@dharmops.com
Website: https://www.dharmops.com

## Services

### Managed DBA Service — Fractional DBA on Retainer ($2,500–$10,000/month)
A managed DBA service gives companies ongoing access to a senior database administrator on a monthly retainer, without the cost of a full-time hire. DharmOps provides proactive monitoring, slow query detection and remediation, index analysis, schema review, backup verification, capacity planning, and on-call incident response.

**What is a managed DBA service?** A managed DBA service (also called a fractional DBA or DBA on retainer) is an ongoing engagement where a senior database administrator monitors, optimizes, and supports your databases on a fixed monthly fee. It covers the same scope as an in-house DBA at 30–70% lower annual cost.

**How much does a managed DBA cost?** A managed DBA retainer from DharmOps runs $2,500–$10,000/month ($30,000–$120,000/year) depending on scope. An in-house senior DBA costs $123,100 in base salary (US Bureau of Labor Statistics, 2024), with all-in costs reaching $175,000–$300,000/year when benefits, payroll tax, recruiting, and equipment are included.

**What databases does the managed DBA service support?** PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Redis, and all major cloud-managed equivalents: AWS RDS, Aurora, Google Cloud SQL, Azure SQL Database, and Cloud Spanner.

Three tiers:
- Essential ($2,500/mo): Monitoring, alerting, slow query review, backup verification, monthly report. Up to 2 database instances. 4-hour on-call SLA during business hours.
- Professional ($5,000/mo): Everything in Essential plus proactive index analysis, query optimization, schema review, Slack access, 2-hour SLA Mon–Fri. Up to 5 instances.
- Enterprise ($10,000/mo): Everything in Professional plus dedicated named senior DBA, 24/7 on-call with 30-minute P1 SLA, architecture reviews, disaster recovery planning, compliance support (SOC 2, HIPAA, PCI DSS), unlimited instances.

Onboarding takes one week. Average client retention: 18+ months.

More: https://www.dharmops.com/services/managed-dba

### Database FinOps — Cut Cloud Costs 30–40%
Most companies overpay on RDS, Aurora, Snowflake, and BigQuery by 30–40%. Overprovisioned instances, inefficient I/O patterns, and unused Reserved Instance capacity add up fast. We audit your cloud database spend, identify every dollar being wasted, and implement the fixes. Average client recovers the engagement cost in the first month.

- Cloud database cost audit (RDS, Aurora, Snowflake, BigQuery)
- Instance right-sizing with zero-downtime migration
- I/O and storage optimization
- Reserved Instance and Savings Plan strategy
- Ongoing cost monitoring retainer available

Typical result: 30–40% bill reduction. Typical payback period: 90 days.

More: https://www.dharmops.com/services/database-finops

### AI Data Infrastructure — pgvector, RAG, Embeddings
Before you add Pinecone or Qdrant, talk to us. Most teams with under 10M vectors can run semantic search, RAG pipelines, and AI features directly on the PostgreSQL they already operate. Properly tuned HNSW indexes on pgvector deliver 471 QPS at 99% recall — with SQL joins that dedicated vector databases cannot do.

- pgvector setup and HNSW index tuning
- RAG pipeline architecture and implementation
- Embedding storage and chunking strategy design
- Semantic search and recommendation engines
- LLM context storage and conversation memory

More: https://www.dharmops.com/services/ai-data-infrastructure

### Caching Architecture — Reduce DB Load 60–80%
Upgrading to a bigger instance is the most expensive way to fix a read volume problem. A well-designed Redis caching layer reduces database load 60–80% and cuts read response times to under 1ms — without touching your schema. We design the right invalidation strategy so you get speed without consistency bugs.

- Redis architecture design and cluster setup
- Cache invalidation strategy (TTL, write-through, event-driven)
- Session storage and rate limiting
- Database query offloading patterns
- Redis as message broker and job queue

More: https://www.dharmops.com/services/caching-architecture

### Data Engineering — dbt, Kafka, ETL/ELT Pipelines
When analysts spend half their time questioning whether the numbers are right, you have a data engineering problem — not an analytics problem. We build dbt models, ETL/ELT pipelines, and Kafka event streams that keep your data fresh, tested, and consistent across every dashboard.

- dbt implementation and data modeling
- ETL/ELT pipeline design with Airbyte or Fivetran
- Kafka and event streaming architecture
- Airflow or Prefect orchestration
- Data warehouse architecture (Snowflake, BigQuery, Redshift)

More: https://www.dharmops.com/services/data-engineering

### Cloud Infrastructure — AWS, GCP, Azure, Kubernetes
Cloud infrastructure provisioned through the console eventually becomes unmanageable. We build Terraform-managed infrastructure for your database workloads — fully reproducible, reviewable, and ready for regional failover. Designed for 99.99% uptime and right-sized for cost from day one.

- Terraform IaC implementation and migration
- RDS, Aurora, Cloud SQL architecture
- Multi-region failover and disaster recovery
- VPC design, security groups, IAM
- Kubernetes stateful workload design (EKS, GKE, AKS)

More: https://www.dharmops.com/services/cloud-infrastructure

### Backend/API Performance — N+1 Fixes, ORM Audits, Pooling
80% of slow API performance issues trace back to the application layer: N+1 queries from ORM misconfiguration, connection pool exhaustion, or SELECT * where 4 columns would do. Adding a read replica doesn't fix a code problem. We instrument your endpoints, find the actual cause, and fix it.

- N+1 query detection and same-day diagnosis
- ORM audit (Django, Rails, Laravel, Prisma, Hibernate, SQLAlchemy)
- Connection pool sizing and PgBouncer/RDS Proxy setup
- GraphQL DataLoader implementation
- Query plan correlation to application code

More: https://www.dharmops.com/services/api-performance

### Database Troubleshooting & Performance Diagnostics — One-Time Engagements
For teams that need a database fixed once, not managed forever. We diagnose why a database is slow, crashing, or behaving strangely — across PostgreSQL, MySQL, MongoDB, Redis, SQL Server, and Aurora — trace the symptom back to its root cause (missing index, lock contention, connection pool exhaustion, replication lag, stale planner statistics), and hand over a fix plan with the tradeoffs named. No retainer required. Free initial diagnostic.

**What is database troubleshooting?** It's the process of tracing a database symptom — slow queries, crashes, timeouts, replication lag — back to the specific mechanism causing it, using query plans, lock graphs, and metrics, so the fix addresses the cause instead of buying a few quiet hours before it happens again.

- Slow query and query plan diagnosis
- Indexing review and correction
- Lock contention and deadlock analysis
- Connection pool sizing and exhaustion fixes
- Replication lag root-cause analysis
- Crash and outage triage
- Capacity and scaling assessment
- Migration health checks

More: https://www.dharmops.com/services/database-troubleshooting

## Case Studies

- E-commerce platform cuts RDS costs 38% through instance right-sizing and I/O optimization: https://www.dharmops.com/case-studies/ecommerce-migration
- SaaS platform implements pgvector for semantic search, replacing planned Pinecone migration: https://www.dharmops.com/case-studies/saas-platform
- Fintech reduces API p99 latency from 4.2s to 180ms by fixing N+1 queries and connection pool exhaustion: https://www.dharmops.com/case-studies/fintech-performance
- Healthcare system achieves 99.99% uptime with Aurora multi-region failover: https://www.dharmops.com/case-studies/healthcare-ha
- Insurance company migrates Oracle to PostgreSQL with zero data loss: https://www.dharmops.com/case-studies/insurance-oracle-postgresql
- Manufacturing ERP cuts Oracle Reports runtime from 3 hours to 15 minutes (90% faster) and eliminates Oracle Forms timeouts with zero production downtime: https://www.dharmops.com/case-studies/oracle-erp-modernization
- US city traffic system cuts sensor ingestion latency 85% and speeds operational reports 12x while maintaining 99.9% uptime: https://www.dharmops.com/case-studies/traffic-management-database
- PostgreSQL 340GB database with 48GB of table bloat, shared_buffers at 128MB default on a 32GB server, and misconfigured autovacuum: reporting queries reduced from 4 minutes to 17 seconds (14x faster), 48GB reclaimed, disk I/O cut 60% — no downtime, no schema changes: https://www.dharmops.com/case-studies/postgresql-300gb-performance

**What causes PostgreSQL to be slow with a large database (100GB–300GB+)?** The most common causes are: (1) shared_buffers left at the 128MB default — should be 25–40% of RAM; (2) autovacuum misconfigured — default autovacuum_vacuum_scale_factor of 0.2 means 20% of rows must be dead before cleanup triggers, causing massive bloat on large tables; (3) sequential scans because covering indexes are missing for the query's full filter pattern; (4) work_mem at 4MB causing disk-based sorts. Table partitioning by date range can provide a further 50–60% improvement for time-series workloads.

**How to fix autovacuum for large PostgreSQL tables:** Set autovacuum_vacuum_scale_factor to 0.01 at the table level: ALTER TABLE t SET (autovacuum_vacuum_scale_factor = 0.01, autovacuum_analyze_scale_factor = 0.005). Run VACUUM ANALYZE manually to reclaim existing bloat immediately. The default 0.2 scale factor waits until 20% of a table's rows are dead before running — on a 180M-row table that's 36M dead tuples accumulating before any cleanup.

More: https://www.dharmops.com/case-studies

## Free Tools

Interactive tools for database engineers and engineering leaders. No signup, no credit card, instant results.

- SQL Query Analyzer — paste a slow query, get an instant diagnosis across 100 rules: https://www.dharmops.com/tools/slow-query-analyzer
- EXPLAIN ANALYZE Explainer — plain-English breakdown of PostgreSQL query plans: https://www.dharmops.com/tools/explain-analyzer
- Database Cost Calculator — monthly cost of slow queries in engineer time and server spend: https://www.dharmops.com/tools/db-cost-calculator
- Cloud DB Overspend Calculator — estimate savings from right-sizing and Reserved Instance coverage: https://www.dharmops.com/tools/cloud-db-cost-calculator
- N+1 Query Impact Calculator — quantify DB load, latency overhead, and monthly waste from N+1 patterns; shows ORM-specific fix: https://www.dharmops.com/tools/n1-query-calculator
- Data Infrastructure Health Score — 12-question assessment across 6 areas with scored results and top 3 improvement opportunities: https://www.dharmops.com/tools/health-score
- pgvector vs Vector DB Advisor — 6-question decision tree recommending pgvector, pgvector+pgvectorscale, or a managed vector database: https://www.dharmops.com/tools/pgvector-advisor
- Redis Cache ROI Calculator — model latency reduction, DB load drop, and monthly cost savings from a Redis caching layer: https://www.dharmops.com/tools/redis-roi-calculator

**What is a good database health score?** A score above 85% means your data infrastructure is well-optimized across costs, caching, AI/vector, operations, cloud config, and API performance. Scores in the 40–65% range are most common and usually point to gaps already costing money or reliability. Below 40% signals critical issues needing attention soon.

**Should I use pgvector or a dedicated vector database?** If you already run PostgreSQL, need to JOIN vector search results against relational data, and store under roughly 10 million vectors, pgvector keeps everything in one system with no added infrastructure. Past 100 million vectors, or with heavy real-time write volume and no existing Postgres setup, a managed vector database (Pinecone, Qdrant Cloud, Weaviate Cloud) is usually the better fit. pgvectorscale is the right step up for the 10–100 million range when you need to stay in Postgres.

All tools: https://www.dharmops.com/tools

## Resources

- PostgreSQL Migration Guide: https://www.dharmops.com/resources/postgresql-migration-guide
- Database Health Checklist: https://www.dharmops.com/resources/database-health-checklist
- Query Optimization Workshop: https://www.dharmops.com/resources/query-optimization-workshop

More: https://www.dharmops.com/resources

## Blog Posts

### How to Debug Slow SQL Queries: A Step-by-Step Guide
Learn how to find, diagnose, and fix slow SQL queries using EXPLAIN ANALYZE, slow query logs, and proven debugging techniques. Covers missing indexes, N+1 patterns, full table scans, and query rewriting — with real SQL examples throughout.

More: https://www.dharmops.com/blog/slow-sql-query-debugging

---

### PostgreSQL vs MySQL in 2026: A Complete Guide to Choosing the Right Database
A complete PostgreSQL vs MySQL comparison for 2026 covering performance benchmarks, JSON support, replication models, ACID compliance, licensing, and migration complexity — with a practical decision framework for CTOs, architects, and developers.

More: https://www.dharmops.com/blog/postgresql-vs-mysql-2026

---

### Database Backup and Recovery: A Complete Best Practices Guide
Everything needed to build a complete database backup strategy: full vs incremental vs differential backups, point-in-time recovery (PITR) setup, RTO/RPO planning, tool comparison (pg_basebackup, WAL-G, Barman), recovery testing procedures, and compliance retention requirements.

More: https://www.dharmops.com/blog/database-backup-and-recovery

---

### AWS RDS Performance Tuning: A Complete Optimization Guide
How to get maximum performance from AWS RDS: choosing the right instance class, tuning PostgreSQL parameter groups, configuring read replicas, optimizing GP3 storage and IOPS, setting up CloudWatch and Performance Insights, cutting costs, and when to migrate to Aurora.

More: https://www.dharmops.com/blog/aws-rds-performance-tuning

---

### AWS RDS Extended Support Is Doubling in 2026 — Here's What You Owe and How to Stop It
MySQL 5.7 and PostgreSQL 11 on RDS are now in Extended Support Year 3 (since March 1, 2026). AWS doubled the rate on that date. The Year 3 charge is $0.11 per vCPU per hour — a 4-instance setup with 32 vCPUs costs $30,835/year in Extended Support alone, on top of compute costs.

**What is AWS RDS Extended Support?** A paid programme allowing continued use of end-of-life RDS engine versions. Security patches continue at a per-vCPU-hour cost. Engine versions in Extended Support as of May 2026: MySQL 5.7 (Year 3), MySQL 8.0 (Year 1 since April 2026), PostgreSQL 11 (Year 3), PostgreSQL 12 (Year 2), PostgreSQL 13 (Year 1).

**How do I stop paying Extended Support charges?** Upgrade to a supported major version. For MySQL 5.7: upgrade to 8.0 or 8.4. For PostgreSQL 11: upgrade to 14, 15, or 16. Options: in-place upgrade (5–20 min downtime), Blue/Green Deployment (under 60 sec switchover), or Aurora migration. Charges stop the moment the upgrade completes.

More: https://www.dharmops.com/blog/aws-rds-extended-support-2026

---

### PostgreSQL Connection Exhaustion: How to Fix 'Too Many Connections' with PgBouncer
PostgreSQL uses a process-per-connection model — each connection spawns a dedicated OS process consuming 5–10 MB. When connections hit max_connections (default 100), all new connection attempts fail with "FATAL: sorry, too many clients already."

**What is PgBouncer?** A lightweight connection pooler that multiplexes hundreds of application connections onto a small pool of actual PostgreSQL backend connections. Applications connect to PgBouncer as if it were the database.

**Session vs transaction pooling:** Use pool_mode = transaction for most workloads. Transaction mode assigns a backend connection only for the duration of each transaction — the highest multiplexing ratio. Session mode provides no multiplexing benefit.

**pool_size formula:** pool_size = (CPU cores × 2) + effective_io_concurrency. For a db.r6g.2xlarge (8 vCPUs): 17–24 backend connections handles hundreds of application connections.

**Does AWS RDS Proxy replace PgBouncer?** RDS Proxy adds 2–5ms overhead and costs $0.015/vCPU/hour. Self-managed PgBouncer costs ~$15/month with sub-millisecond overhead. Use RDS Proxy for Lambda/serverless. Use PgBouncer for persistent application servers.

More: https://www.dharmops.com/blog/postgresql-connection-exhaustion-pgbouncer

---

### Your API Is Slow. Your Database Probably Isn't the Problem.
80% of slow API performance problems trace to the application layer, not the database. Individual database queries may execute in 1–5ms while API responses take 500ms+. The gap is application-layer behaviour.

**Why is an API slow if database queries are fast?** N+1 query patterns generate hundreds of round-trips per request. Connection pool exhaustion causes wait time before queries start. SELECT * fetches more data than needed. Serial independent queries could run in parallel.

**What is an N+1 query problem?** Code fetches N records then issues one additional query per record to load related data — N+1 round-trips instead of one. Fix: select_related() in Django, includes() in Rails, include: {} in Prisma.

**How to detect N+1 in production:** Query pg_stat_statements for queries running thousands of times per hour with near-identical structure. Use nplusone (Django) or bullet (Rails) in development.

Real result: p99 from 4.2 seconds to 180ms by fixing three N+1 patterns in one API endpoint — no infrastructure changes.

More: https://www.dharmops.com/blog/slow-api-not-the-database

---

### PostgreSQL 18: Every Performance Improvement You Need to Know
PostgreSQL 18 entered public beta April 2026. GA expected Q3 2026. Key improvements:

**Short query throughput:** 20–30% higher TPS for OLTP workloads vs PostgreSQL 17 in pgbench benchmarks.

**Vacuum improvements:** Vacuum now only scans index pages containing dead tuple references — 40–60% less vacuum I/O on large indexes in high-write environments.

**Planner improvements:** Better statistics for partial index predicates, reducing row estimate errors on selective partial indexes.

**Logical replication:** Large transaction streaming reduces lag spikes during migrations and bulk operations.

**pgvector + AI:** Short query gains benefit RAG embedding lookups. Improved planner statistics produce better plans for hybrid vector + SQL predicate queries.

**Is PostgreSQL 18 production-ready?** Beta only as of May 2026. Test against a production clone now; upgrade after GA (Q3 2026).

More: https://www.dharmops.com/blog/postgresql-18-performance-improvements

---

### The Database FinOps Guide: Stop Overpaying for Cloud Databases
Cloud database bills grow through overprovisioned instances, idle read replicas, GP2 storage paying for IOPS that GP3 includes free, On-Demand pricing on always-on production instances, and high-I/O queries doing full table scans on every request.

**What is Database FinOps?** The practice of continuously measuring, optimising, and governing cloud database costs — covering rightsizing compute, eliminating idle resources, switching from GP2 to GP3 storage, purchasing Reserved Instances, and reducing query-level I/O costs through indexing and caching.

**7 biggest sources of database waste:** (1) Oversized compute instances running at 10–25% average CPU. (2) Idle read replicas persisting after the workload that created them changed. (3) GP2 storage over-paying for IOPS vs. GP3 which includes 3,000 IOPS and 125 MB/s free. (4) High-I/O queries doing sequential scans generating IOPS charges on every execution. (5) Missing caching — read-heavy workloads hitting the database for data that rarely changes. (6) Excessive backup retention (35 days on dev/staging databases). (7) On-Demand pricing on production instances that qualify for 38–42% savings with 1-year Reserved Instances.

**4-step Database FinOps cycle:** (1) Visibility — tag all RDS resources, pull 30-day CPU utilisation, enable pg_stat_statements. (2) Rightsizing — flag instances below 30% average CPU, review read replica utilisation, assess Multi-AZ on non-production. (3) Performance optimisation — identify top queries by shared_blks_read, add indexes to eliminate sequential scans. (4) Governance — monthly cost review, quarterly rightsizing, annual query cost review.

**Real example:** SaaS company reduced from $8,200/month to $5,050/month ($38,000/year saved) by: rightsizing staging instances (−$280/mo), deleting idle read replica (−$670/mo), migrating GP2 to GP3 (−$410/mo), reducing backup retention (−$190/mo), purchasing Reserved Instances (−$1,100/mo). No application code changes.

**How much can Database FinOps save?** For organisations spending $3,000–$15,000/month on RDS, a structured FinOps review typically identifies 25–40% in reductions without application changes.

More: https://www.dharmops.com/blog/database-finops-guide

---

### Managed DBA vs. Hiring In-House: The Full Cost Breakdown for 2026
Most engineering leaders underestimate the true cost of an in-house DBA by 40–60% because they think salary, not total cost.

**What is a managed DBA service?** Ongoing senior database administration on a monthly retainer — monitoring, query optimization, on-call incident response, schema review, backup verification, and performance governance. Starting at $2,500/month.

**Cost comparison:** In-house senior DBA: $123,100 median base salary (US BLS, 2024) + benefits + payroll tax + recruiting = $175,000–$300,000/year fully loaded. Managed DBA retainer: $30,000–$120,000/year. Managed is 30–70% cheaper with a 1-week onboarding vs 3–6 months recruiting.

**When hire in-house:** Compliance prohibits external DB access, need daily product team embedding, or 50+ database instances. **When managed wins:** Under 150 employees, under 20 instances, no DBA on staff, or cross-platform expertise needed.

**Onboarding timeline:** 7–10 days: access setup + monitoring (days 1–2), baseline assessment (days 3–4), first findings report (days 5–7).

More: https://www.dharmops.com/blog/managed-dba-vs-hiring-in-house

---

### pgvector vs Pinecone in 2026: Benchmarks, Cost, and When to Use Each
Most teams evaluating vector search start with the assumption that a serious AI application needs a dedicated vector database. pgvector's HNSW indexing and PostgreSQL 18's throughput gains have shifted the decision boundary significantly.

**Short answer decision table:**
- Existing PostgreSQL app → pgvector
- RAG MVP → pgvector
- Under 10M vectors → pgvector
- Hybrid SQL + vector search needed → pgvector
- Cost-sensitive startup → pgvector
- Large-scale AI platform (core product) → Pinecone
- 100M+ vectors → Pinecone
- Fully managed, no PostgreSQL expertise → Pinecone

**What is pgvector?** An open-source PostgreSQL extension that adds vector similarity search to an existing PostgreSQL database. Uses HNSW or IVFFlat indexing. Free, no additional infrastructure. Enables hybrid SQL + vector queries in a single statement.

**What is Pinecone?** A purpose-built, fully managed vector database delivered as a SaaS API. You send embeddings via API; Pinecone handles indexing, sharding, scaling, and availability. Adds a new vendor, billing relationship, and operational surface.

**How the gap narrowed since 2023:** HNSW indexing (pgvector 0.5.0, May 2023) dramatically improved recall — with ef_search=100, pgvector HNSW reaches 97–99% recall on ANN Benchmarks (1M vectors, 1536 dimensions), comparable to Pinecone's production recall. PostgreSQL 18's 20–30% short-query throughput gain directly benefits embedding lookup workloads.

**Performance:** At under 10M vectors with HNSW index fully in RAM, pgvector on db.r6g.2xlarge delivers p50 latency under 5ms, p99 under 25ms. Pinecone delivers similar p50 with lower p99 variance at large scale. In practice, vector search is not the latency bottleneck in most RAG pipelines — LLM generation adds 500ms–3s.

**Cost at three workload sizes:**
- 500K vectors: pgvector costs near-zero on existing PostgreSQL. Pinecone adds $0–$50/month plus vendor overhead.
- 5M vectors: pgvector may require instance upgrade to db.r6g.2xlarge (~$510/month). Pinecone runs $70–$200/month. Comparable infrastructure cost; pgvector is one system.
- 100M+ vectors: HNSW index no longer fits in RAM on practical instances. Pinecone's distributed architecture handles this scale without instance sizing decisions.

**The hidden cost most teams ignore:** Adding Pinecone to a stack that already includes PostgreSQL means another vendor contract, API authentication, SDK dependency, monitoring integration, SOC 2 security review item, and failure mode. For teams under 20 engineers with under 50M vectors, this operational overhead exceeds the infrastructure cost difference.

**pgvector's unique advantage — hybrid SQL + vector search:** A single SQL query can combine semantic similarity with relational filters (user_id, category, price range, subscription tier). Pinecone cannot do relational JOINs — hybrid queries require multiple API round-trips between Pinecone and your relational database, adding latency and complexity.

**When to migrate pgvector → Pinecone:** When vector count exceeds 50–100M and instance sizing becomes a recurring burden, OR when vector search is so central to the product that performance isolation from the database workload is a reliability requirement.

**Is pgvector production-ready in 2026?** Yes. With HNSW and ef_search=100, recall is 97–99%, competitive with dedicated vector databases. Used in production by many SaaS companies for RAG pipelines, semantic search, and recommendation workloads under 10–50M vectors.

**Can PostgreSQL replace Pinecone?** For most applications under 50M vectors, yes. At 100M+ vectors with high query volume and no relational filtering requirements, Pinecone's managed horizontal scaling provides operational advantages that PostgreSQL cannot match without pgvectorscale.

**Cheapest vector database option?** For teams already running PostgreSQL, pgvector is free. The only cost is compute for the HNSW index in RAM. At 1M vectors this adds no cost; at 5M it may require an instance upgrade of $150–$300/month.

More: https://www.dharmops.com/blog/pgvector-vs-pinecone-2026

## What Is the N+1 Query Problem?

**Summary:** The N+1 query problem occurs when an application executes 1 query to retrieve N records, then fires N additional individual queries for related data — instead of using a JOIN or batch query. One API call fetching 100 users triggers 101 database queries. At 1,000 users: 1,001 queries. At 10,000 users: 10,001 queries. Query volume scales linearly with data volume.

**Why it matters:** At 5ms per query, 101 queries add 505ms of database overhead per request before any application logic runs. At 100 requests per second with 50 unnecessary queries each, the database fields 5,000 unnecessary queries every second. N+1 inflates API latency, raises database CPU, exhausts connection pool slots, and drives cloud costs up — while adding no useful work.

**Root cause:** ORM lazy loading. ORMs like Django ORM, ActiveRecord (Rails), SQLAlchemy, Prisma, Entity Framework, and Laravel Eloquent defer fetching related records until the relationship is accessed in code. Iterating over a queryset and accessing a related field on each object triggers a new database query per iteration. The code looks like a simple loop; the database sees hundreds of individual SELECT statements.

**Why read replicas don't fix it:** N+1 is an efficiency problem, not a capacity problem. Adding a read replica distributes the unnecessary queries across more servers. It does not reduce their count. 500 unnecessary queries remain 500 unnecessary queries across two servers.

**How to detect N+1 in production:**
- pg_stat_statements: query for calls > 500 with mean_exec_time < 20ms — high-frequency, low-latency queries are the N+1 signature
- Django: Django Debug Toolbar (per-request query count and source), Silk (request profiling)
- Rails: Bullet gem — fires runtime warnings when lazy-loaded associations should be eager-loaded
- Laravel: Telescope, Laravel Debugbar
- APM: Datadog, New Relic, AppSignal, Elastic APM — endpoint traces showing 200+ database calls flag N+1 immediately

**Five fixes:**
1. Eager loading: prefetch_related() / select_related() (Django), includes() (Rails) — 1 line, 90%+ query reduction
2. SQL JOINs: LEFT JOIN retrieves parent + related records in one round trip
3. Batch queries with IN: collect IDs first, then SELECT * FROM orders WHERE user_id IN (...)
4. DataLoader for GraphQL: batches all resolver calls for the same entity type into one query per request cycle
5. Query count budgets: define max queries per endpoint, enforce in integration tests, treat breaches as failures

**When N+1 becomes architectural:** Rising database CPU proportional to data volume (not traffic); read replicas accumulating with diminishing returns; API latency worsening despite infrastructure upgrades; cloud costs outpacing business growth; no one on the team can explain the database load.

More: https://www.dharmops.com/blog/n-plus-one-query-problem

---

## Why Is My AWS RDS Bill So High?

**Summary:** High AWS RDS bills typically trace to seven causes: overprovisioned compute (instances running at 10–25% average CPU), idle read replicas left over from past workloads, inefficient queries generating excess IOPS, storage waste from retained manual snapshots, gp2 storage paying for IOPS that gp3 includes free, On-Demand pricing on production instances that run 24/7, and infrastructure upgrades applied to efficiency problems that indexing would have fixed.

**The six RDS cost categories:** Compute (50–65% of most bills), storage, IOPS, backups and snapshots, data transfer, and Multi-AZ/read replica compute. Identify which category is growing fastest in Cost Explorer before diagnosing causes.

**gp2 vs gp3:** gp3 costs $0.092/GB/month versus gp2's $0.115/GB/month. gp3 includes 3,000 IOPS and 125 MB/s throughput at no extra charge. gp2 gives 3 IOPS/GB baseline — a 500 GB database gets 1,500 IOPS; additional IOPS cost $0.065/IOPS-month. gp3 additional IOPS cost $0.02/IOPS-month. Migration from gp2 to gp3 is live with no downtime.

**Reserved Instances vs On-Demand:** A db.r6g.2xlarge costs $0.48/hour On-Demand — $3,513/month. The 1-year No Upfront Reserved rate is $0.296/hour — $2,173/month. Saving: $1,340/month or $16,080/year per instance. Break-even: ~7 months. Rightsize before committing.

**15-minute cost audit:** Pull 30-day average CPU per instance (below 30% = rightsizing candidate); check FreeableMemory (above 30% of RAM = possible downsize); list replicas and check DatabaseConnections (below 5 per day average = idle); query pg_stat_statements top 20 by shared_blks_read (cache_miss_pct above 50% = I/O cost driver); verify storage type (gp2 = migration candidate); check backup retention on non-production (above 14 days = review); check pricing model (On-Demand on 24/7 production = Reserved Instance candidate).

**Case study:** SaaS company, $6,500/month to $4,200/month. Findings: primary instance at 22% CPU; one replica averaging 2 connections/day; two sequential scan queries on a 30M-row table running 150x/minute; 47 retained manual snapshots; all instances on On-Demand. Fix: rightsize primary, remove idle replica, add two covering indexes, delete snapshots, purchase 1-year reservations. Annual saving: more than $27,000.

More: https://www.dharmops.com/blog/why-is-my-aws-rds-bill-so-high

## Free Diagnostic

Book a free 30-minute call with a senior DBA. We review your database setup and the problems you're experiencing. By the end of the call, you know what's causing the issue and whether we're the right team to fix it. No pitch — just an honest assessment.

Book: https://www.dharmops.com/contact?service=diagnostic

## About

DharmOps brings deep, cross-platform database expertise across PostgreSQL, MySQL, Oracle, and major cloud database platforms. We work hands-on — no subcontractors. Clients include SaaS companies, fintech firms, healthcare systems, e-commerce platforms, and enterprise teams across North America and Europe.

More: https://www.dharmops.com/about