Hello everyone!
Today, we are re-launching Fortress as a Postgres developer platform for global replication and managed sharding.
Initially, at Fortress, we focused on building a Postgres solution for multi-tenant B2B applications. In particular, we were interested in a cross-cloud (BYOC) solution for B2B apps to meet their customers’ security requirements.
To do this, we implemented a sharding system that allowed different tenants to live on isolated Postgres clusters (essentially it was a super basic version of Proxy-based Citus, or Vitess for mySQL, sharded based on tenant_id). However, while talking with some of the first developers who used our product, we learned that the ‘multi-tenant’ management for security wasn’t as big of a ‘sell’ as we had initially hoped (more details on this below).
For that reason, we pivoted away from that messaging. While multi-tenant SaaS apps are still a great use-case we want to support, we decided to shift our focus to allowing Postgres to scale out for global deployments. We learned from a few people who we spoke to that they were more interested in being able to deploy shards of data in different regions (geo-sharding) to reduce application-database latency. They wanted to use the global edge, but it often didn’t make sense with a centralized database -> they wanted a cheap distributed database solution. Currently, most of the available solutions targeted for this use case are SQLite-based (like Turso or D1) as it was more cost effective than Postgres and other networked databases.
Further, the existing Postgres solutions, like Supabase & Fly.io offered global replication but didn't offer extensive support for write-forwarding, routing, sharding, or managing costs of maintaining a bunch of replicas. Distributed solutions that are Postgres-compatible like Yugabyte and Cockroach seemed to be more focused on High Availability for enterprise use-cases rather than developers deploying on edge.
We believe that there are a few reasons why now is the time for a Postgres based edge solution for developers:
- The cost problem of Postgres can be solved in two ways (a) allowing global replicas to be in logical databases in shared multi-tenant clusters, (b) a serverless approach that separates compute and storage can make idle global replicas cost very little. We opted for the first for now but we will evaluate this more in the future, especially since it appears that (b) looks promising to be the correct approach for cloud-native Postgres (i.e Neon).
- Native logical replication, especially with the updates in Postgres 17, is becoming a more robust way of moving data with failover slots. This can enable some cool ways of replicating data across global replicas in conjunction with typical streaming replication from the WAL stream.
- Postgres is just becoming more of a standard for new developers and startups.
We focused the past few weeks on reorienting our platform and built a system that allowed for automatic geo-based routing. This allows developers to interact with just a single Postgres connection string and Fortress will do automatic routing to the closest replica under the hood. In the future, we will be exploring Multi-master implementations.
Our philosophy is to build on top of native Postgres without making changes to the database itself. We understand that naturally, building a middleware layer (shared-nothing) will naturally reduce Postgres compatibility, but we believe that it is important to stay close to native-Postgres.
We are excited to open up Fortress for early users. We will be opening up the free-tier for early users these next two days and would love to hear feedback on what we are building and would love to work with developers to build out apps through our platform.
Why didn’t the multi-tenant messaging work for us?
We were primarily targeting early stage startups and thought that providing a ‘secure’ Postgres solution out of the box was enough of a hook to attract B2B companies, especially since we constantly heard pain-points in setting up RLS and access-controls within Postgres. Multi-tenancy was something that these developers were clearly thinking about, especially for security purposes. But from our experiences, it just wasn’t big enough of a draw to get the ‘earliest’ stage of companies where development speed and simplicity is much more valued (in fact, we heard stories of startups intentionally not setting up RLS as it slows down development speed...)
For these companies, when they had customers that required data isolation, they just resorted to creating a full-single-tenant application+database for that customer - it wasn’t until these B2B companies reached a sufficient scale where they actually consolidated to a multi-tenant App + dedicated db architecture for cost efficiency and at that point, many were already used to their existing database provider.
Nevertheless, even though we are pivoting from this messaging, we believe that multi-tenant B2B is a use-case we want to continue supporting in the future. We still believe that it should be easy for developers to build in a responsible way and want to enable that with Fortress.
An interesting note on proxy-based sharding:
An interesting thing we realized was that while the initial design choice to use a proxy-based approach to sharding (instead of just using Citus) was purely due to the fact that it was the way to be compatible with RDS (as we wanted to enable BYOC initially), we realized it afforded some other benefits, especially when it came to globally distributing Postgres shards. For example, it allows us to easily horizontally scale the routing layer, across regions, instead of being bottlenecked by a stateful coordinator node.