infra_dev

Nile CEO here. Thanks for the feedback. Let me try to explain it a bit.

Modern SaaS applications are multi-tenant. We’re the first database that virtualizes tenants into the database. A tenant is primarily a company, an organization, or a workspace in your product that contains a group of users. This enables seamless tenant isolation, per-tenant backups, and placement on multi-tenant or dedicated infrastructure, anywhere on the planet. You can do all this with the experience of a single Postgres! You don’t have to manage multiple databases, build complex permissions for isolation, or write buggy scripts to read specific tenant data from backups. On top of the tenant model, we provide opt-in user management capabilities, customer-specific vector embeddings, and instant tenant admin dashboards.

You manage schemas like how you manage with standard Postgres. Your favorite tooling should work. When you make the schema change, Nile pushes the schema to all the tenants. For the user, it is like interfacing with a single Postgres instance.

We have built a Rust based layer internally to manage tenants, route them, shard them if needed and have multiple tenants talk to each other. Happy to chat more. My email is ram@thenile.dev

Nile CEO here. We work out of the box with Django. We are working on providing examples and tutorials for Django soon.We definitely want to play well with the ecosystem.

Nile CEO here. Nile provides tenant virtualization. Each tenant has a group of users within them. Typically, you would choose one location for a tenant. This will be based on your customer location. This would mostly stay the same. The users in a company could travel, but the choice of region is usually decided by where the company is located. Yes, you would be able to change the location of a tenant and the data will be moved to a new region but this usually happens if there is a major decision about location in a company.

This is Ram, the author of the post. We have not unveiled our product yet. We are currently focussing on talking about the architecture that Infrastructure SaaS companies have to build and scale. The control plane and data plane are the critical parts of the architecture. We plan to post more blogs about different topics around these architecture patterns. I would love to chat 1:1 about what we are building if you are interested. My email is ram@thenile.dev

This is Ram, the author of the post. Thanks for the feedback. The architecture that is mentioned in the post is something we built at a startup for our providing our infrastructure as a service. It is true that this architecture gets complex in larger companies. I would love to understand what parts are abstract and how we can improve them. We plan to publish a series of posts to provide more clarity on the different parts mentioned in the blog. Your feedback would be really helpful.

Hey smashah, this is Ram, the author of the post. Everything that you said is pretty spot on. It is a really hard problem and pretty repetitive in many of the companies including open source projects. We hope to build a platform that can help with this and over time cover all the use cases you mentioned.

Great question! For a typical B2B SaaS, you typically will have a multitenant deployment in one region. The control plane APIs and data plane APIs will run in the same region. Each new customer will create a logical tenant in your DB but there are no physical data planes created.

For Infrastructure SaaS, it is a bit different. You typically will have different customers provision your infrastructure in different cloud or regions depending on where they have their infrastructure. This leads to having many physical infrastructure deployed in many regions and cloud providers. At the same time, for the user, you need to provide a single pane of glass experience where they can manage all their infrastructure from a single dashboard. This requires a central control plane that is responsible for all the life cycle management operations and it helps to communicate all the metadata back and forth to all the data planes. Things like upgrades, observability, user and tenant management all need coordination with the data planes. This makes the Infrastructure SaaS use case a bit different from standard B2B SaaS. Hope that helps.

Hey ed, this is Ram, the author of the post. In the context of Infrastructure SaaS, a data plane is the system that is the infrastructure that you provide as service. For example, let us say you are building a company that provides Postgres as a service. In this case, Postgres is your data plane. Typically, your users will want the Postgres to be deployed in a specific region or cloud provider.They would run queries against the Postgres cluster.

Control plane is the central lifecycle management system that helps provide all the SaaS experience for your Infra SaaS application, manages the metadata for your application and also pushes this information to all the data planes. Example of lifecycle management operations could be creating an user, a new organization, provisioning your data plane in a specific region, deleting a cluster etc.

The data plane is your product that you want to sell to your customers and control plane is the central system that helps you to make your product work in a self serve way with your customers.

This example can also be mapped to internal use cases. Many companies manage their own infrastructure internally and end up having to build a central control plane to manage all the different infrastructure that they provide as a service to their developers. Hope this helps.

Hey, this is Ram, the author of the post. Would love to know how this architecture works in production for you. For infrastructure saas, the control plane needs to manage 100's of data planes. It also needs to own user and tenant management, security policies, billing based on usage, usage and operational insights for your users. The challenge is in building an infrastructure that can centrally manage the lifecycle of all the metadata (SaaS, app and infra) and orchestrate with all the data planes. Postgres is definitely a good building block to build on top of but there is so much to build around it to make this work well in our experience.