[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 : 115 points
Date : 2024-09-02 16:58 UTC (1 days 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.
| rrr_oh_man wrote:
| _> 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?
| 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)
| Kinrany wrote:
| Do they have an article that explains their approach? I
| couldn't get through the marketing-speak.
| 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.
| DowagerDave wrote:
| >> 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.
| 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.
| 0xferruccio wrote:
| 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
| 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.
| SahAssar wrote:
| > "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.
| 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
| ahoka wrote:
| "each tenant is isolated storage-wise."
|
| How is this defined? What is considered separated?
| 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.
| lclarkmichalek wrote:
| 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.
| simplyinfinity wrote:
| 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.
| lclarkmichalek wrote:
| You rather explained the value prop of this product then.
| The benefits of isolation without the 1 business day wait.
| voidfunc wrote:
| 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.
| wiradikusuma wrote:
| But it'll take 10 business days to get an OK from
| management and other departments.
| davecyen wrote:
| 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
| Kinrany wrote:
| A blog post explaining these two common approaches would
| solve the same problem though
| blacksoil wrote:
| "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
| seanhunter wrote:
| 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.
| tomhallett wrote:
| Is there a list anywhere of these types of checks you do
| which are critical to approving a saas vendor?
| seanhunter wrote:
| 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.
| HeyLaughingBoy wrote:
| 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?
| loktarogar wrote:
| 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.
| buremba wrote:
| 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.
| willothy wrote:
| 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.
| breadwinner wrote:
| Does Fortress add any value if SaaS product is creating Neon.tech
| instances for each tenant?
| nojvek wrote:
| 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.
| ibgeek wrote:
| 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?
| willothy wrote:
| 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.
| taherchhabra wrote:
| Congratulations on your launch. would you mind elaborating why
| you pivoted from AI web scraping.
| carlual wrote:
| 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
| moxplod wrote:
| 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?
___________________________________________________________________
(page generated 2024-09-03 23:01 UTC)