> For the complete documentation index, see [llms.txt](https://docs.hardpoint.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hardpoint.dev/who-is-hardpoint-for.md).
# Who is Hardpoint for?
## Overview
Hardpoint simplifies the process of adding **tenant isolation**, **data residency** and **compliance features** to your existing SaaS product, without the cost and risk associated with big re-writes.
Retrofitting these capabilities typically becomes a concern when you:
* Increase your focus on sales to enterprise-segment customers
* Enter a new territory where prospects have different privacy/regulatory expectations
* Undergo an information security certification process such as **ISO 27001** or **SOC 2**
* Are starting to apply "platform thinking" to your existing feature set
### The balancing act
Implementing this functionality often adds extra workload to already contended product & engineering roadmaps, and increases the operational burden for technical team members who weren't hired to deal with compliance.
If you're finding yourself forced to make the decision between:
* Building platform functionality that's not core to your value proposition, or;
* Continuing with your product roadmap and losing enterprise deals
then Hardpoint may be an appropriate technology choice to offload the responsibility of making your SaaS 'enterprisey'.
***
## What Hardpoint does, in a nutshell
Hardpoint turns a requirement like:
> Customer X needs their data to be stored in Germany and they want dedicated DBs
Into a set of software-defined policies like:
```
{
"group": "customer_x",
"entry_rule": "req.tenant_id in [x9889x7, h88s8s7, p99f743]",
"placement": "DE-FLK",
"separation": "per_key"
}
```
Which routes traffic to the correct jurisdiction, and partitions data to the correct DB, without platform engineers having to build any of this machinery internally.
***
## When to use Hardpoint
Hardpoint can be a great fit if:
* You're *not* building from scratch: you've already gone from 0 -> 1 and tenant isolation is something you now need to retrofit
* You're invested in PostgreSQL, MongoDB or Redis\*[^1]
* You're running workloads on a serverless/edge PaaS such as [Vercel](https://vercel.com/) or [Fly.io](https://fly.io)
* You view creating duplicate, dedicated cloud networking and database infrastructure as an architectural (and financial) last resort
* Your products' existing SIEM integration and key management capabilities are in *early maturity* and/or *nonexistent*
* You have *not yet* invested significant engineering resources into managing fleets of data stores, cloud accounts, e.t.c
* You need an out-of-the-box mechanism for warehousing and/or deleting inactive tenant data, either to improve performance of pooled databases, for cost-control or for compliance (e.g. GDPR)
***
## Where Hardpoint fits into your stack
In its simplest setup, you can start running tenant-isolated data through Hardpoint by simply integrating the [SDK](/guides/hardpoint-enterprise/getting-started/install-the-sdk.md) with your app and writing a couple of [traffic rules](/guides/hardpoint-enterprise/getting-started/create-rules.md).
### Before
Let's take a commonplace modern SaaS architecture as an example:
* A web framework such as [next.js](https://nextjs.org/)
* Services which are deployed to a PaaS[^2] such as Vercel
* Application state stored in a relational database such as PostgreSQL, often via a managed service such as [RDS](https://aws.amazon.com/rds/) or [Neon](https://neon.com/)
In this arrangement, databases are typically pooled across all tenants; separation of tenant data is achieved either through simple tenant identifiers, or via row-level security (RLS). We explore the nuances of different isolation patterns on [this page](/tenant-isolation.md).
### After
After integrating Hardpoint into this SaaS app, we've achieved full database-per-tenant isolation. The key points which changed are:
* The application's persistence layer now obtains DB connections through a secure tunnel, transparently managed by the [Hardpoint SDK](https://github.com/hardpointlabs/sdk). Instead of obtaining credentials from config files or environment variables, the applications' ability to connect to a database for a given tenant is evaluated dynamically, and the tunnel uses ephemeral, short-lived credentials to access and modify tenant data. No shared secrets or other sensitive material is needed to obtain database access
* [Hardpoint Lattice](/guides/hardpoint-lattice.md) is now the managed PostgreSQL provider: instead of configuring full Postgres instances in a managed cloud provider and deciding deployment region ahead of time, Hardpoint Connect evaluates tenant placement on-demand, locating the database and automatically provisioning it, if necessary. The lightweight nature of Lattice databases compared to a traditional Postgres clusters makes it economically viable to own and manage dedicated databases for each tenant.
Crucially, aside from tweaking the DB connection mechanism, all of this is transparent to the application and the deployment environment: no queries needed rewriting, no application logic changed and the deployment model remains the same.
#### More information
A major change in your SaaS storage layer should be rolled out *incrementally* rather than all at once, and Hardpoint is designed with this in mind. Consult the [migration strategies](/guides/hardpoint-enterprise/migration-strategies.md) documentation for more information about various techniques for rolling out Hardpoint, and their respective advantages & trade-offs.
***
## When Hardpoint may not be a good fit
Hardpoint leverages several modern architectural practices and system-level tools to make tenant isolation accessible to more SaaS operators. However, like all products, it makes some tradeoffs in order to focus on its key use cases. Therefore there are some cases where Hardpoint may not be the optimal choice:
* Since the [Hardpoint Connect](/guides/hardpoint-enterprise.md)'s control-plane is managed, Hardpoint isn't suited to customers who require fully air-gapped deployments (however it *can* work for customers who need their data to run in *non*-air-gapped, on-prem deployments)
* [Hardpoint Lattice](/guides/hardpoint-lattice.md) is not a drop-in replacement for vanilla PostgreSQL, MongoDB or Redis; if you rely on exotic functionality, plugins or corner-case behavior in these products, Hardpoint *might* not be appropriate (you can still use Hardpoint Connect as a standalone service)
* If your product's data model does not naturally treat tenant data as a discrete unit, you may run into performance bottlenecks with Lattice. Use cases such as social networks, which perform many cross-tenant lookups, are unlikely to work well
* While the Hardpoint platform can work with any combination of programming language ecosystem and cloud environment, we're strongly optimizing the developer experience for node-compatible runtimes, and PaaS/FaaS runtimes such as Vercel or Fly.io *(however we have incubating support for various Kubernetes distributions)*
[^1]: MongoDB and Redis are invite-only at present. We'd love to hear from users who need other data stores
[^2]: Platform As A Service: a cloud computing model where a service provider abstracts away the infrastructure concerns, letting you focus on releasing changes faster