Solving Search in Multi-Cloud Customer Deployments
If you're redesigning your SaaS product to run in your customers' cloud environments, you've likely hit this wall: the managed services you depend on don't exist consistently across every cloud.
Quick context: Tensor9 helps SaaS vendors deploy to customer environments (AWS, GCP, Azure, on-prem). You write your infrastructure once; we compile it to each customer's specific environment. This post explains how we're extending that capability to search with Lucenia, alongside existing patterns for Elasticsearch and OpenSearch.
Your app likely relies on Elasticsearch or OpenSearch. This works seamlessly on AWS thanks to the native OpenSearch Service. But the architecture becomes complex when you land an enterprise customer on Azure, or a federal customer with an air-gapped environment.
Suddenly, you are facing a fragmentation problem: you have to choose between maintaining separate deployment paths for every cloud or finding a "common denominator" that runs everywhere.
Service Equivalents With Tensor9
At Tensor9, we build tooling that helps SaaS vendors deliver their products into customers’ cloud and on-prem environments. The core mechanism that makes this work is something we call service equivalents.
The idea is simple: cloud providers offer similar services under different names and APIs. AWS RDS, Google Cloud SQL, and Azure Database for PostgreSQL are all, effectively, managed PostgreSQL. They share the same wire protocol but use different packaging. Tensor9 maintains a registry that maps these services to their functional equivalents across environments.
Examples from Tensor9’s Service Equivalents Registry. See the full list in our documentation
With Tensor9, your origin stack gets compiled to the target environment. For example, for a GCP customer we map S3 to the GCP equivalent, Google Cloud Storage. Your application code doesn't change; we handle endpoint injection so your app connects to the right service in each environment.
This works beautifully for databases, caching, and object storage because wire-compatible managed services exist almost everywhere. Search, however, presents a unique challenge.
The Search Landscape: Balancing Availability vs. Cost
Search is one of the few categories where the hyperscalers (AWS, GCP, Azure) do not offer a uniform, native managed service.
AWS: Offers native managed OpenSearch.
GCP & Azure: Do not have a native equivalent; they rely on third-party integrations or self-hosted configurations.
This asymmetry leaves SaaS vendors with a decision tree when deploying to GCP, Azure, or on-prem:
The Commercial Managed Route (Elastic Cloud): You can utilize Elastic Cloud, the managed service provided by Elasticsearch. It offers robust features and availability on GCP and Azure. However, it introduces an external vendor dependency and a premium cost model that may not align with every customer's budget, particularly in single-tenant deployments.
The Self-Managed Route: You can run OpenSearch or Elasticsearch clusters on VMs or Kubernetes. This removes the licensing fees but introduces operational complexity—you become responsible for the uptime, scaling, and management of the cluster.
Expanding the Ecosystem with Lucenia
To solve this gap, Tensor9 is introducing support for Lucenia as a service equivalent for search.
Founded by Nick Knize - who created the OpenSearch fork at AWS - Lucenia is an Elasticsearch/OpenSearch-compatible search engine built specifically for modern cloud-native environments.
We are integrating Lucenia into the Tensor9 registry because it offers a third option: a portable, consistent search primitive that runs identical infrastructure across all clouds.
Why Lucenia Fits the Service Equivalent Model
API Compatibility: Lucenia is a drop-in replacement for Elasticsearch and OpenSearch. It uses the same client libraries and queries. This allows your application code to remain agnostic to the underlying provider.
Unified Architecture: Unlike using AWS OpenSearch in one region and Elastic Cloud in another, Lucenia allows you to deploy the exact same Kubernetes-based search architecture in AWS, Azure, GCP, and Air-gapped environments.
Cost Efficiency: For high-volume workloads or single-tenant customer deployments, Lucenia creates a significant opportunity to optimize infrastructure costs compared to premium managed services.
Air-Gap Native: For federal and regulated markets, Lucenia functions in completely disconnected environments, solving a major hurdle for public sector deployments.
How It Works: Service Equivalents with Lucenia
By adding Lucenia to the registry, we can now map your search requirements as follows:
AWS Customer: App + RDS + S3 + OpenSearch Service or Lucenia
GCP Customer: App + Cloud SQL + GCS + Lucenia
Azure Customer: App + Azure DB + Blob + Lucenia
Air-gapped / Federal: App + CNPG + MinIO + Lucenia
What This Enables for SaaS Vendors
Consistency Across Clouds
You can write your app using standard Elasticsearch client libraries. When deploying to AWS, we can utilize the native OpenSearch Service or Lucenia. When deploying to GCP, Azure, or on-prem, we can compile the infrastructure to use Lucenia. The application logic remains untouched.
Opens Federal Markets
Federal customers often cannot use public cloud managed services due to strict compliance or connectivity requirements. Since Lucenia runs on private Kubernetes, you can serve these customers without building a separate "federal edition" of your product.
Cost Optimization
Some customers want to reduce their dependency on cloud vendor lock-in or optimize costs. Lucenia gives them that option while keeping your deployment story simple.
Architectural Choice
This approach moves away from vendor lock-in. Whether you prefer the convenience of a managed service or the control and cost-profile of a self-hosted engine, the Tensor9 platform supports the mapping that best fits your business model.
Ecosystem Outlook
We are actively working with the Lucenia team to integrate their deployment mechanisms with our platform.
It is important to note that while Lucenia is API-compatible, every search engine has nuances. Advanced features specific to proprietary Elasticsearch licenses (such as certain Machine Learning nodes) may have different implementations in the open ecosystem. We encourage vendors to evaluate their specific feature usage.
Our goal at Tensor9 is to give you the building blocks to deploy anywhere. By adding Lucenia to our service equivalents, we’re turning search from a multi-cloud headache into a standard, portable component.
Learn More
Lucenia.io – Cloud-native search and analytics
Tensor9.com – Deploy SaaS to any customer environment
Service Equivalents Docs – Full registry of supported services with Tensor9
