[HN Gopher] Launch HN: Fortress (YC S24) - Database platform for...
___________________________________________________________________
Launch HN: Fortress (YC S24) - Database platform for multi-tenant
SaaS
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!
Author : dchu17
Score : 75 points
Date : 2024-09-02 16:58 UTC (6 hours ago)
| sifex wrote:
| FYI I can't really see the code examples on mobile.
| dchu17 wrote:
| Thanks for letting us know, fixing it now!
| jph wrote:
| 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?
| dchu17 wrote:
| 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!
| rrr_oh_man wrote:
| 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"
| dchu17 wrote:
| 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.
| samstave wrote:
| > 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 :-)
| john2360 wrote:
| 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.
| samstave wrote:
| 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_pe
| opl...
| GordonS wrote:
| > 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.
| yodon wrote:
| 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.
| dchu17 wrote:
| This looks super interesting! Will check it out. Thanks for
| letting us know!
| mffap wrote:
| 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)
| brap wrote:
| 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?
| dchu17 wrote:
| 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.
| pfix wrote:
| I feel targeted. Internal platform team. How to solve db
| instance sizing vs utilization.
| willothy wrote:
| 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.
| hobs wrote:
| 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.
| john2360 wrote:
| 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.
| richardw wrote:
| 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.
| john2360 wrote:
| 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.
| 0xferruccio wrote:
| 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"
| john2360 wrote:
| 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.
| 0xferruccio wrote:
| My opinion is that there's a $100m ARR business that you can
| build by just being "Planetscale for Postgres"
| samlambert wrote:
| 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.
| andrewstuart wrote:
| 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.
| john2360 wrote:
| 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?
| andrewstuart wrote:
| 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.
| adhamsalama wrote:
| TIL, thanks!
| mmastrac wrote:
| 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...
| andrewstuart wrote:
| 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.
| rvnx wrote:
| (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.
| sidcool wrote:
| It's answered in the description above.
| sidcool wrote:
| Congrats on launching. Looks promising.
| nullorempty wrote:
| How do you support local development?
| rvnx wrote:
| 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
| john2360 wrote:
| 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.
| john2360 wrote:
| We don't currently support local database development, but we
| are working on making that possible!
| potamic wrote:
| Do you think cloud providers will all provide multi-tenancy as a
| native feature eventually? What's your strategy for that?
| john2360 wrote:
| 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!
| adam_gyroscope wrote:
| How does this compare to Nile? (thenile.dev)
| dchu17 wrote:
| 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.
| SahAssar wrote:
| 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?
| john2360 wrote:
| 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
| SahAssar wrote:
| 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.
| debarshri wrote:
| 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.
| john2360 wrote:
| 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?
| debarshri wrote:
| 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
| simplyinfinity wrote:
| 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.
| Lionga wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-02 23:00 UTC)