While we hope to share similar DXs, our fundamental difference is that we are focused on a BYOC-first platform instead of a serverless Postgres platform. We realized that developers who were doing strict tenant-isolation were only doing it as a means to meet their customer's demands to close deals. Often, database isolation is not the only requirement; there are requirements on which cloud a database can be hosted on, or even asks to host the database on a private cloud. For these reasons, we thought that the BYOC angle gave us more flexibility to solve these problems as well as providing a easy-to-use interface.
When talking to a specific customer, in my experience, it's better to not use phrases like "we know that many companies JUST LIKE YOU do X and Y". That seems unpersonal and frankly, a bit like a smartass.
Better:
- Reply directly to their concerns and questions without any fluff.
- Ask the customer about their problems, wants, and needs. Maximize your understanding of their problem space.
- And: Throw out the jargon. [0] It sucks.
[0] "provide a unified platform that developers can trust to provide native isolation"
We still definitely need to work on our language to best communicate this; we'll work on keeping it more concise and straightforward to best highlight what we offer.
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.
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?
We've seen most SaaS companies use some sort of tenant_id column and this is definitely the most popular method that developers currently use.
We want to provide a few things for SaaS developers. For one, many SaaS companies will face the need to create a completely new isolated database instance and may need to deploy this instance on a specific cloud (we know that Azure is really popular for healthcare).
Further, we want to spare the dev-experience of using WHERE clauses and/or setting up RLS. We aim to provide a seamless DX that abstracts over where the tenant data actually is and provide a unified platform that developers can trust to provide native isolation. We are pretty early but want to hear whether these resonate with you!