Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Fortress (YC S24) – Database platform for multi-tenant SaaS
121 points by dchu17 40 days ago | hide | past | favorite | 82 comments
Hi HN! We're Will, John, and David from Fortress (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?..., as well as a walkthrough of our Python SDK: 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) 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). We created a video of us walking through the example with Fortress (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!




Speaking as a dev with over 12 years of experience in both dev and ops, that has implemented and maintained multiple multi-tenant systems with different levels of multi-tenant isolation (infra, db, schema, table, shared tables).

I dot see the value proposition here. Let's take couple of examples

If I need to have my totally separate infra for each tenant I'm going to go for terraform

If I need separate database on the same db infra, I'm Goin to either have a db initialization script that creates a usable db or clones a template database already present

So why do I need your sdk? To avoid a call to postgres to execute a script or a terraform script?

How does that work with the need for prefilled data?

Maybe I'm missing something, but I do not understand this service.


Personally, there's no way I'd want a customer initiated operation to trigger something like terraform or mess with DB schemas. On the security side, it would significantly complicate the permissions structure from the application to the database. And on the performance side, I have absolutely no mental model for how operations like that scale, and how trivial of a DoS I'm exposing myself to. At the same time, I love the isolation (mostly operationally, the security & privacy side is also nice) that db-per-customer would bring. If this product helps bridge the gap, then it sounds good to me.


Last project I worked on was a mix of on prem software and cloud software.

The cloud counterpart had 600+ mongodb databases split amongst 3 Mongo clusters.

The integration team took usually 2 weeks to setup the on premises software, and the cloud stuff took about a minute. The entire setup for the cloud was a single form that the integration team filled in with data.

The point I'm trying to make, is that if your customers require separate infra, they can wait a bisuness day to be setup. Meanwhile they can play on a sandbox environment.

It's also doable in fully automated fashion, but you will have to have strong identity and payment verifications, to avoid DoS, and in those cases usually contracts fly around.

That's for the b2b side.

For b2c, usually you rely on a single db and filter by column ID or similar, which can easily be abstracted away.


You rather explained the value prop of this product then. The benefits of isolation without the 1 business day wait.


What exactly is the value prop tho? To a technical person 1 business day wait seems dumb, but few businesses move that fast where waiting a single day matters.


But it'll take 10 business days to get an OK from management and other departments.


you might consider that it's precisely your depth and breadth of experience, which isn't common across most teams, might actually highlight why a solution like Fortress is valuable


A blog post explaining these two common approaches would solve the same problem though


"Speaking as a dev with over 12 years of experience in both dev and ops"

I think you aren't the target market. The target market is probably people who are new to coding or even self-taught indie hackers who aren't too technical but oriented towards building a product as quickly as possible


OK I have been the ultimate decision-maker in a number of SaaS vendor selection situations so I am the target market for people who would build an offering using this. I can tell you that multi-tenant shared anything is pretty much an absolute dealbreaker for me and most people like me. Why?

1) In any financial regulated environment your regulator will usually specifically require this (at least in jurisdictions I'm familiar with). Am I prepared to go to battle with my regulator on behalf of a vendor? Most definitely not.

2) Even if I'm not in that situation, do I trust the vendor to have tech protections that work well enough that my customer data won't leak if there's some sort of problem, leading to a GDPR/data protection nightmare? No. No I don't trust anyone that much. I wouldn't even trust code that I myself had written that much (ie when I have built b2b saas solutions I have insisted on single tenant shared nothing). I've actually used (a demo of) a multi-tenant saas where the vendor has insisted on the security of their multitenant solution and been shown another customer's data on more than one occasion.

3) Even if I did trust the vendor and wasn't in a regulated environment which required single tenant, would I be prepared to go to war with my internal legal counsel over the data protection implications of multitenant? No. I want to keep a good working relationship with them and their life is hard enough as it is. They want single tenant shared nothing that's good enough for me.

4) Even if none of the above applies a lot of big corporates will want the option to host a solution in a cloud subaccount that they own. That's clearly not on the cards with something like this.


As someone whose background is primarily in embedded systems, how common are single tenant SaaS architectures?

The only webapps that I've released commercially were all intended for internal use by a single customer, running on their private hardware, with usually only a single login, so I'm about as far from this space as you can get and still be a dev...

I was always under the impression that most SaaS was multitenant, with the individual tenants sharing tables, but being disambiguated by customer ID. Am I that far off?


A lot of "enterprise" b2b saas systems with relatively low customer numbers, relatively high ticket price per sale are going to be single tenant. Think things like core banking systems[1] which have very sensitive end-customer data (in that case balances and transactions) in them. No bank would be allowed by their regulator to put that in a multi-tenant system even if they would want to which I don't think they would.

Also any system which could notionally be multitenant but the customer is a tech-savvy large enterprise and wants to bring their own cloud. That's de facto single tenant because they're not going to host anyone else's instance are they? So where I work there are a few saas vendors we deal with where we have set up AWS subaccounts where they have some access and they host an instance of their thing in there just for us. Saas vendors will frequently do this if the contract /client is valuable enough, so it's pretty common in an enterprise context.

[1] Mambu, Thought Machine etc


Is there a list anywhere of these types of checks you do which are critical to approving a saas vendor?


I don't know, but search for "saas vendor due diligence" and you should find a bunch of stuff. Every big corp I've been in the approval seat has a different process so it's not standardized for sure but generally the basic process is the vendor sends out the questionnaire as an excel sheet and provides a box folder or something to dump the evidence in, and then there are a couple of zoom calls to talk through any questions or concerns. There are certification type things like iso 27001 and isae 3402[1] and although they make this process easier because you will rip the bandaid off and take all the pain in one hit I wouldn't recommend a startup go for those right away[2].

[1] https://isae3402.co.uk/isae-3402-and-iso-27001

[2] Going for them will suck up a lot of energy, focus and time and you can't really tell which ones your clients are going to ask for in what order so there is the danger that you get the priorities wrong which would be a bad mistake in the early stage of a saas startup. So what I would recommend is you read through those and whatever nist guidelines and stuff like that and bear them in mind as you build your product, then start researching who you will get to do your ISAE/ISO27001/SOC1/SOC2 audit when you need one, then when the first client says have you got ISAE3402 (or whichever other one) you say "we're working towards it" (which is true) and as soon as you get off the call with your client call your preferred audit vendor and start the process. "We're working towards it" is an acceptable answer for most big corps because they know the process is slow (iirc it takes a minimum of 6 months for any of those because you have to demonstrate the process over time) and they are slow anyway so they don't mind it taking a minute for you to get it done. Then once you have one, the next time a client asks you for that one you have it, and if they ask you for a different one you say "we have <x> already and are working towards <y>" and rinse and repeat. It's going to be easier this time because you'll be able to repurpose some of the stuff you produced for the first one for the second and so on.


Maybe it has some great AI web-scraping (what ever that means but it is combining the two of the most parasitic domains together) included.


If I understand this correctly it's mainly a UI to create new instances of postgresql on existing platforms that offer it as a service or create clusters/databases (in the postgresql jargon) on those. Seems like the SDK is a wrapper for existing libraries to provide connection string for connecting and not much else. Is that correct?


Thanks for the question! In addition to helping with DevOps tasks, we built the infrastructure to help you securely manage your tenants in shared and dedicated instances. The shared instances have logical data separation, so there can be no data leakage. Our goal was it make it so developers did not have to worry about that infrastructure or security. - John


I'm still not sure what fortress actually does that is new.

What I'm guessing is that if you have a isolation=shared tenant you add a database to an existing postgresql cluster and if it is set to isolation=dedicated you setup a separate cluster? The clusters are setup with normal postgresql hosted solutions like AWS aurora and billed in the same way, right?

If so I don't understand why I'd use your product over any traditional IaC like CDK or terraform where I have done similar stuff (spin up multiple instances/clusters/databases based on tenants) and seems to integrate better with existing devops tooling or a workflow on top of CDK/terraform scripts that creates databases/schemas.


Am 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?


Thanks for the feedback!

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!


> Further, we want to spare the dev-experience of using WHERE clauses

A laudable goal, but one which is easily solved at library level, or at the "infrastructure code" level. I've been doing this across a range of databases for several years.


Feedback for the feeback to the feedback:

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"


Thanks for the criticism!

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 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.

That sounds like an AT&T customer service chatbot.

Do you speak like this to other people, in day-to-day life?


> DX that abstracts over where the tenant data actually is

This goes against any of the main items that @jph closed with: COMPLIANCE.

So - abstracting the implementation complexity is difference than abstracting the "where data lives" - especially with Compliant requirements such as SOX and HIPAA, wtc. -- Its been a while but I've done some significant sized HIPAA and SOX, SAS70 and other compliance audits - and one of those reqs is "data retention for ~7 years" in many compliance laws... and so abstracting where data resides no beuno. (Surely you didnt mean that literally?)

I am currently working on am 10DLC compliant SMS routing platform... and so I get to dive back into compliance - and I know already I have to know where all my flows tick KPIs in a way I can visibly and empirically document life-of-a-data

And "Secure, Multi-tenant DB Routing as a Service." might be a better DNA for the tag-line.

--

Also, I think I recall youre previous HN announcement for the AI scraping?

But - in conjunction with this, it would be great to have a PWA-DB that is my own RLS multi-tenant for my personal data that I own all my records and companies have to subscribe to RLS access to my PII and blacklist all databrokers and scrape for who has my PII so I can actively manage who is accessing any of it - (Using both of your AI Scraper/Crawler tool and some-version of this seems like that could be a reality)

(I love what youre doing - as other HNers said, Got to get the right CorpoSpeak bolted on here for BigBanko :-)


That makes complete sense. A little correction from what David was saying: We don't want to abstract away the data stores; we want you to have complete ownership and observability of that. However, we want to make the infrastructure easy to manage, set up, and interface with. This is why we are making a big push to BYOC to allow you full data ownership. I like the direction of your tag line. Making sure that our security and privacy mission is loud and clear is important.

That is a super interesting idea. We have also been really tickled with the idea of owning our own data, and that is somewhat of the mission that drives us to make data security and privacy more accessible for developers. I love the connection to scraping.


Its important to realize just how powerful and important a good AI scraper actually is - especially one that can now route to a RLS-level-DB-Connector - whereby I can pull a scrape, then use the BYOC asa router to place my scrapes into various catergories where I am using the idea of a tenant as a bucket for information. And if I can then do views on those data-sets based on the app-straction one needs.

The example is that this can apply smart DB insertion into tables where youre using RLS as the route-ing rule that says "Any [fields of [this_type] from [urls] go [DB.schema.table.row]" and then provide views to these based on whatever presentation you want a component to view that data, like a structured form dynamically screaped into view with a RLS view rule...

(Just look at all the recent posts to HN where all these legos have basically been put up in the last 3-months.

Al Erector-Sets are currently being assembled and the amount of tool-age is mind-blowing awesome)

This prompting post on reddit was really interesting:

https://i.imgur.com/xJALx30.png

https://old.reddit.com/r/ClaudeAI/comments/1exy6re/the_peopl...


I think you have a lot of potential customers who know they have a multi tenant challenge but don’t know that they have a “don’t roll your own” challenge. Most multi tenant systems fail open rather than fail closed and leak data very easily. Forget a where clause? Query should find no data, not everyone’s data.

Always try to find ways to remove an entire class of problem.


Thanks for your thoughts! John here. We completely agree with you, and that's the premise of Fortress. We abstract away all the security risks and vulnerabilities of building your own solution.


>> We abstract away all the security risks and vulnerabilities of building your own solution.

Maybe... but don't I trade that for your risks and vulnerabilities? And you're a small startup so it's tough for you to play the obvious "expert-specialist" card at this point. I think you need a strong value prop at this stage.


Multi-tenant stuff is very interesting to me.

Do you provide any per-tenant resource limits or prioritization (storage, memory, network [rates plus total], CPU)? Anything to limit the impact of noisy neighbors?

Do you provide per-tenant accounting (for billing) capabilities?


Those are absolutely things we're looking to support, especially in the case of monitoring / accounting. Isolated tenants don't face the noisy neighbor problem here, but tenants in shared databases still may at the moment. One possible solution we're looking at there is to move towards a serverless approach where every tenant has isolated storage and ephemeral worker VMs perform the queries.


Would be nice to have ActiveRecord integration for Ruby/Rails. It's nice to have the same API for all languages, but AR is pretty much the standard for Rails SaaS and you're adding a lot of work that Ruby devs don't generally need to do otherwise.

Not to say that effort is or isn't worth it, but Rails companies will have to _really want_ what you offer to build on it, and your call if it's worth investing that effort on your side or not.


If you’re interested in row level access control on Postgres, it works like this:

Prior to doing queries, you do a SQL query that sets a “Postgres environment variable”.

In very simplified terms, after that, queries automatically have a WHERE clause applied which ensures only rows with the value of the env variable are returned.

This is a good thing because it means you do not have to write WHERE customer = ‘blah’ anywhere.


Adding to parent comment's context -- it's specifically called "row-level security". The docs show a number of examples for this:

[0] https://www.postgresql.org/docs/current/ddl-rowsecurity.html

  -- a policy on the account relation to allow only members of the managers role to access rows, and only rows of their accounts
  CREATE TABLE accounts (manager text, company text, contact_email text);

  ALTER TABLE accounts ENABLE ROW LEVEL SECURITY;

  CREATE POLICY account_managers ON accounts TO managers
    USING (manager = current_user);
EDIT: That page doesn't cover session vars, but this one does:

https://www.crunchydata.com/blog/row-level-security-for-tena...


Yep thanks for fleshing it out.

After configuring it as the parent post says, you set the environment variable like so:

SET myapp.manager = '123e4567-e89b-12d3-a456-426614174000';

Then you can just query the database and it will only return records where manager = '123e4567-e89b-12d3-a456-426614174000'

It's something like that anyway - you have to do lots of reading the docs and fiddling to make sure all the bits and pieces are set up right for it to work - which is why these folks are creating a SAAS to do all the thinking for you.

The real benefit of RLS is developers don't have to put "WHERE company_id=whatevere" on all queries, along with the risk that leaving it out or writing it wrong will reveal one client's data in another clients user interface.


> “Postgres environment variable”

I think most people think of environment variables as being for a whole process. For RLS this can be any GUC variable so it can be per-session, per transaction, etc.

Usually you would set it per transaction (and start a transaction for each request) and I think the important part you are missing to say is they are applied to any joins, CTE's, functions and views (as of the latest-1 version with the right flag).

So you write your schema, write your access (RLS) rules and can then write your queries as if you had access to the whole DB but the only parts you will see is what that user can access.


John here. Interesting! So, this is a per-session variable? Right now, we provide our customers with full logical separation in the same cluster. Do you have a preference for RLS or logical separation?


I used RLS in Django by intercepting all outbound SQL and wrapping each statement in the commands to set the Postgres variable.

Note that a Postgres environment variable is not an operating system environment variable.


TIL, thanks!


Congrats on your launch. There are some very mature solutions out there https://www.citusdata.com/use-cases/multi-tenant-apps/

What's the comparison with citus?


Do you support scaling to zero? I wonder if native offerings of cloud providers (Cloud SQL/Alloydb or Aurora) still make sense as keeping hundreds of PG instances at scale will likely be a challenge if you're managing them from your control plane.

Also, is there any compliance that requires it to be in different Postgresql servers? I assume most companies just use some sort of isolation (tenant_id column or dedicated tenant database/table) so I wonder if this problem could better be solved as a proxy layer.


We support scaling to near-zero because of Aurora serverless, but we definitely are looking into other solutions that could be cheaper to run or self-hosted.

Some regional regulations (GDPR, etc.) require local and/or isolated hosting. Most companies indeed solve this with either a tenant id column, dedicated tenant databases or both. We want to simplify those architectures, and a proxy layer is exactly our idea there - we're working on a solution that handles connection pooling and routing to remove the need to cache connections on the client.


(edited from a different question) It could be interesting to pivot as a layer on top of Supabase ?

Like "we protect / monitor / audit / lock your Supabase instance".

RLS is an easy pitfall there, and it's a database used by a lot of SaaS products.

You wouldn't get the pain of managing clusters, and at the same time, you get the good role, and companies who care about data safety can use it as additional security assurance.


It's answered in the description above.


FYI I can’t really see the code examples on mobile.


Thanks for letting us know, fixing it now!


Congratulations on the launch! That’s really an innovative way to enforce tenant isolation. Curious to hear people’s toughts on another interesting approach:

https://zenstack.dev/blog/multi-tenant#innovative-approach


At Adaptive (https://adaptive.live), we working with lot of orgs in regulated space. for eg. this setup will not pass compliance requirements for multi-tenancy for Reserved Bank of India, where the expectation is that each tenant is isolated storage-wise.


I like your product. I think that data observability is super important for the future. Did you have to implement something similar to Fortress for your client?


Does it use postgres underneath? If yes, then it would support out of the box. More than happy to hop on a call and chat more about your product and our learnings working with regulated orgs. I think most of your market might be there. Reach me at - debarshi[at]adaptive[.]live


“each tenant is isolated storage-wise.”

How is this defined? What is considered separated?


Great question. It is not defined. Generally, in my opinion, segregation at a protocol level passes audit very easily i.e A DB per tenant. Based on my experience what I have seen is that the line of questioning and the idea is around, if someone gets access to a databases, does that attacker get access to all the data or just the data of the tenant.


Does Fortress add any value if SaaS product is creating Neon.tech instances for each tenant?


At my current workplace, we deal with this via postgres schema per tenant. We have a script that ensures every schema has the same tables, indices and permissions. Scales pretty well.

I just wish postgres on AWS had better ability to separate compute and storage.


You might check out the work https://wristband.dev is doing on multi-tenant auth. My read is it's complimentary to what you're doing rather than competitive.


If you prefer an open source, and maybe more mature, alternative for multi tenant/b2b auth then have a look at https://zitadel.com (disclosure: work for zitadel)


Do they have an article that explains their approach? I couldn't get through the marketing-speak.


This looks super interesting! Will check it out. Thanks for letting us know!


Reading "Database platform for multi-tenant SaaS" scared me and made me think you're building another Database

IMO the tagline should be a "Postgres platform for multi-tenant SaaS"


John, here. Thanks for the feedback. I see where you are coming from, and we will work on that tagline. Our goal is to be database and cloud provider agnostic.


My opinion is that there’s a $100m ARR business that you can build by just being “Planetscale for Postgres”


i take this as a compliment. i don’t however believe it’s this simple. PlanetScale is PlanetScale because of Vitess and MySQL’s combined reliability and scalability. there are companies out there trying to be PlanetScale for Postgres and they can barely keep two 9’s of uptime which is kind of missing the point.


I agree it’s going to be really hard to do, but I do think there’s an opportunity there for someone to make something that helps companies run Postgres at scale reliably.

I think most companies aren’t really working to appeal the higher end of the market when trying to be “Planetscale for Postgres” - the focus seems to mainly be easy developer experience and faster iterations for startups


This 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?


This 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.


I feel targeted. Internal platform team. How to solve db instance sizing vs utilization.


Hey 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.


Do you think cloud providers will all provide multi-tenancy as a native feature eventually? What's your strategy for that?


That is a super interesting question. I don't think we are too worried about cloud providers building this feature natively right now. While they can do that for specific database product lines, we don't think we will see that universally across their products. Our goal is to be database and cloud provider agnostic. So even if cloud providers build multi-tenancy natively, you will still have to manage it across all your different clouds. Thanks for the question!


How does this compare to Nile? (thenile.dev)


We really like Nile and it is definitely a company we look towards for inspiration!

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.


Congrats on launching. Looks promising.


Congratulations on your launch. would you mind elaborating why you pivoted from AI web scraping.


Yep! Just felt it wasn't for us. We originally built it for e-commerce as just a better way to get product data than through affiliate APIs but felt like most of the market pull weren't in things we were interested in.


I think the big wins for something like this would be where you can say to a company "you are SOC2 compliant on your database if you do this and don't export data to your laptops" and frankly the people who are going to care the most about this are going to be either the Very large companies or those targeting Very large companies, and they are going to have a different sales cycle than this looks like it will naturally have in a YC context.

I have worked on bigger data sharing stuff, and the smaller clients have no interest in paying the single tenant tax, and the huge folks wont hear anything but.


Hi, this is John, one of the co-founders. Thank you so much for the feedback. We agree with you. We are in the process of getting our SOC2 compliance. We want to be the data infrastructure that is immediately HIPPA, SOC2, and GDPR. Similar to what Porter builds on your cloud, it is SOC2.


Good luck, it is truly a tax on your ability to ship, but if you solve it well its a huge moat.


How do you support local development?


Conceptually Fortress (if I understood it right) is like if you have a variable postgres_hosts looking like this:

    postgres_hosts['local'] = {host: localhost, user: 'abcd', password: DECRYPT_AES('defh'), dbname: 'base'}
    postgres_hosts['customer1'] = {host: prod1, user: 'saas_panel', password: DECRYPT_AES('pwdpanel'), dbname: 'base'}
    postgres_hosts['customer2'] = {host: prod2, user: 'saas_panel', password: DECRYPT_AES('pwdpanel'), dbname: 'base'}

    postgres_connection = connect(postgres_hosts[customer_id])
What Fortress does is maintaining that list of hosts for you:

    postgres_hosts = fetch('http://api.fortress.../{api_key}/postgres_hosts')
When you want to create a new customer in your system, you call fortress.create_tenant, and from their backend they will use your GCP/AWS credentials to create a new host and add it to the list (correct me if I'm wrong)

So in theory you could have only 'local' as a host in your .env.development file, and enable Fortress for production mode


Exactly! That is a high level of what is happening in the background, but in the foreground, all you have to do is reference the tenant's ID. We also manage key rotations and other nitty gritties to secure your databases.


We don't currently support local database development, but we are working on making that possible!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: