Frequently Asked Questions

Anything that involves an Elasticsearch, OpenSearch, or observability stack that's misbehaving or being built fresh. Typical work:

• New cluster design and deployment
• Performance rescue for existing clusters
• Query and aggregation tuning
• Index design and data modeling
• Elastic Observability (APM, RUM, logging) buildouts
• Cluster migrations and version upgrades
• Elastic ↔ OpenSearch migration assessments
• Amazon OpenSearch Service vs Elastic Cloud honest tradeoffs
• HA and DR setups
• Security hardening and compliance work

Brand-new build, mid-life crisis cluster, or full rescue — any of those is fair game.

Yes, and we see this constantly. Most of the deep performance problems we get called into started with relational thinking:

• Documents aren't shaped around query patterns
• Indexes get treated like tables
• Way too many shards created way too early
• Dynamic mappings growing with nobody watching
• Joins, deep pagination, and big aggregations adding load nobody budgeted for

We work through schema, mappings, templates, query patterns, shard layout, and retention until the cluster matches how the system actually gets used.

Depends on the scope:

• Quick assessments: 1–2 weeks. Diagnostic + written recommendations.
• Optimization projects: 2–8 weeks. Query tuning, index work, performance fixes we actually implement with you.
• Full implementations: 1–3 months. New cluster design, deployment, and stand-up.
• Advisory retainer: Monthly. Staff+ judgment on demand for the team.

We'd rather match the shape of the problem than push you into a bigger engagement than you need.

Yes — we work across all the usual environments:

• AWS: EC2-based clusters, Amazon OpenSearch Service, self-managed Elasticsearch/OpenSearch
• Azure: VMs and self-managed clusters
• GCP: Compute Engine, GKE-based deployments
• Hybrid: Multi-cloud and on-prem-to-cloud migrations

Cloud, hybrid, self-managed — same principles, different operational quirks.

Highly dependent on the starting point, but typical ranges from engagements we've run:

• Query latency: 50–80% lower average response times
• Indexing throughput: 2–5x more docs/sec
• Resource use: 30–50% less CPU and memory
• Infra cost: 20–40% reduction through right-sizing alone
• Headroom: Room to grow without re-architecting in 6 months

We'll baseline your current numbers first so the "after" is measurable, not vibes.

Yes — this is a big chunk of what we do. Safe, low/no-downtime work:

• Major version upgrades (7.x → 8.x, 8.x → 9.x)
• Cluster-to-cluster migrations
• On-prem to cloud, or cloud-to-cloud
• Reindex strategies and data validation
• Rolling upgrades with minimal disruption
• Post-migration tuning

We plan rollback before rollout. So far it's kept us out of trouble.

Workload first, architecture second. In practice:

• Requirements: Data volumes, query patterns, growth projections — what's actually true today
• Architecture: Node roles, shard allocation, index structure, data distribution
• Capacity: Right-sizing nodes, storage, network
• HA/DR: Multi-node setups, replica strategy, disaster recovery that's been tested
• Security: AuthN, AuthZ, encryption, compliance baked in
• Observability: Monitoring and alerting from day one — not bolted on after the first incident

The goal is a cluster that fits today's workload and still works after 18 months of growth.

Yes. Knowledge transfer is part of every engagement, not an upsell:

• Operations: Day-to-day cluster management, monitoring, troubleshooting
• Query work: Writing efficient queries and aggregations, avoiding the usual traps
• Index design: Modeling, mappings, ILM
• Performance: How to find and fix bottlenecks without us on the call
• Docs: Custom runbooks for your environment, not generic boilerplate

When we're done, you shouldn't need us to keep the cluster running.

Pretty simple:

1. Reach out: The form on the home page or cbrown@nosqlrevolution.com
2. Quick call: 15–30 minutes for us to understand what's broken or what you're building
3. Proposal: Scope, timeline, price — written down, no surprises
4. Kickoff: If we're a fit, we start with a focused assessment of the current state

Most engagements start with a performance assessment or architecture review so we both know what we're dealing with before committing to bigger work.