10 ms·
Launch HN: Fortress (YC S24) – Database platform for multi-tenant SaaS
Hi HN! We're Will, John, and David from Fortress (https://fortress.build https://fortress.build). We're building a Bring Your Own Cloud (BYOC) backend as a service for multi-tenant SaaS apps, simplifying tenant data isolation across both shared and dedicated database instances.
There’s a demo here: https://www.loom.com/share/761cac3090ba4db8b2ce9d713873333a?sid=d76b31bb-100c-483e-ba26-60915d98e61a https://www.loom.com/share/761cac3090ba4db8b2ce9d713873333a?..., as well as a walkthrough of our Python SDK: https://www.loom.com/share/c4b3f95235e24d99a7ea571c4564602b https://www.loom.com/share/c4b3f95235e24d99a7ea571c4564602b
YC initially funded us for AI web-scraping, but early in the batch we realized we wanted to pivot to something in data privacy - in some ways the opposite of web-scraping…
From talking with SaaS developers, we learned tenant isolation (making sure one customer’s data is not shown to another) is often considered in development but rarely a core competency. Many developers struggled setting up Row-Level-Security (RLS) correctly on Postgres, some are enforcing application level access controls with none at the database-level at all, and many didn’t know which multi-tenant db architecture to start with and just decided to deal with it later. However, with increasing data sensitivity and compliance requirements, they’ve seen growing customer demand for stricter data requirements, including more demands for dedicated database instances or even databases deployed on the customer’s private cloud.
We also learned that SaaS developers prefer to have databases on their own cloud, and many who start on a 3rd party DBaaS eventually move infrastructure to their own cloud later. Having things on your own cloud makes it easier for SaaS to offer on-prem/full-siloed deployments and meet compliance requirements for larger customers. So we pivoted into being a BYOC platform and made Fortress integratable with cloud-native databases.
Our goal with Fortress is to give SaaS developers the ease of use of a managed DBaaS, native isolation for tenants, and the ability to programmatically provision and access database instances on any cloud.
Fortress provides SaaS developers an abstraction at the tenant level, allowing them to enforce tenant isolation through a function without having to set up RLS themselves or use WHERE statements in every query. Currently, on the Fortress platform, this is simple as every tenant in a shared database is given a logical db in a Postgres Cluster and we handle routing (We are currently working on a solution that provides native tenant isolation for tenants stored in shared tables).
Through our SDKs, developers only need to handle one connection to the Fortress client and we'll route requests and handle connection caching to ensure minimal latency to the right tenant’s data. We are working on creating more SDKs and simplifying existing ones. We currently support Postgres via AWS Aurora with plans to support other cloud-native databases and open-sourced databases via Kubernetes.
If you want to try it out, we’ve opened up self-serve to spin up new databases on your AWS cloud. You will need to create an account with Fortress (https://fortress.build/auth/sign-up https://fortress.build/auth/sign-up) to connect it to your own AWS account - that’s what BYOC (Bring Your Own Cloud) means! But if you are uncomfortable with granting us IAM permissions, we are offering a free db on the managed Fortress cloud for you to test out our SDKs (just cancel out of the Integrations page, create a database on the Database page, and select managed as the option, you will have a limit of 1). Note: AWS takes a while to spin up new clusters, adding tenants to existing clusters should be fairly instantaneous.
To provide you something basic to play with, we created a simple python flask application where you can easily test out our python SDK (https://github.com/fortress-build/python-example https://github.com/fortress-build/python-example). We created a video of us walking through the example with Fortress (https://www.loom.com/share/0245bec78d9d4dbeba8836c4112aa5da?sid=fd79eea1-d71a-4cb9-8a3d-a870dfb6f5d3 https://www.loom.com/share/0245bec78d9d4dbeba8836c4112aa5da?...)
We hope you’ll test it out! We wanted to launch on HN to hear honest criticism, ideas, and pain points in this space. We are a super early stage database product and recognize that we have a ton of room for improvements. Looking forward to your input!
- brap 2y agoThis seems interesting, but I can’t quite figure out what your target audience is. Can you give an example of a theoretical customer and how they would use your product?
- dchu17 2y agoThis is a great question :) We initially targeted startups at the moment that they are moving from a 3rd party DBaaS to databases on their own cloud. However, we just realized this was super tough to time. We experimented a bit with enterprise actually too but many of them already have huge systems in place. We are shifting our focus to SaaS developers. We know that often, thinking about data isolation is a factor on SaaS developers' minds. We want to build a platform where they can have an incredibly simple DX while also trusting that their customer data will be isolated.
- pfix 2y agoI feel targeted. Internal platform team. How to solve db instance sizing vs utilization.
- willothy 2y agoHey Will here, another Fortress cofounder. We're still thinking about this a lot. We're using AWS Aurora currently which auto-scales compute and storage, and are looking into other options such as distributed databases (Cockroach, etc.) and Kubernetes operators.
- sifex 2y agoFYI I can’t really see the code examples on mobile.
- dchu17 2y agoThanks for letting us know, fixing it now!
- jph 2y agoAm I your target customer? Here's my two cents: your FTUX has so many steps and so many tour popups, and IMHO these are overwhelm your value prop. You have an opportunity to focus more on your value prop first and foremost. If you like, I can give you my actual use cases. I use AWS, and I use multi-tenant Postgres such as with a tenant_id row, as well as multi-region setups, and for some projects one database per end organization tenant. On AWS I use Aurora and also some self-managed Postgres. Some of the Postgres extensions I use are for geofencing, trigramming, etc. and these ideally could/should have tenant-specific instantiations. I code using Go & Rust. I work in regulated industries that use SOX, HIPAA, FERPA, etc. Can you speak to if/how the Fortress value prop can help me, and if/how/when to get the API in Go and Rust?