DEV Community: sriramsub

🚀 We just shipped Nile-Auth v4.0: Account Linking, CORS Support, and More

sriramsub — Fri, 11 Apr 2025 19:28:07 +0000

We just released a major update to Nile-Auth, an open-source authentication service for B2B apps.

Try it out and let us know

🆕 What’s New in v4.0:

Account Linking

Users can now authenticate with multiple providers (e.g., GitHub + Google) under one identity.
Cross-Origin Request Support

Auth now works across frontends/backends on different domains or hosts.
Configurable Routes

Define and customize your auth flow endpoints.
Tailwind V4

Updated styles for our prebuilt auth UI components.
New JavaScript SDK Docs

SDK Reference is clearer, more complete, and easier to follow.
Tons of New Examples

We’ve added auth workflow examples to help you implement common scenarios fast.

📜 Full Release Notes:

https://github.com/niledatabase/nile-js/releases/tag/v4.0.0

Introducing Nile Auth for B2B apps

sriramsub — Fri, 28 Mar 2025 13:55:10 +0000

Today, we are excited to introduce Nile Auth, a comprehensive B2B authentication solution explicitly designed for multi-tenant applications. Nile Auth is fully open source and built on top of Nile’s Postgres. It allows you to store user and customer data in your Postgres database, giving you complete control over your information. You can choose to self-host Nile Auth or utilize our cloud version.

Integrating authentication into your B2B application on the front and back end takes just a few minutes with Nile Auth’s B2B authentication features and customizable UI components. If you choose the hosted version, you can enjoy unlimited active users for authentication at no additional cost; you only pay for the database.

Try it out today and effortlessly add authentication to your B2B app in just a few minutes!

Adding B2B Auth to your app in 2 minutes

Before I explain the principles behind Nile Auth, let's examine how easy it is to integrate it into your B2B app.
Install the Nile SDK that will handle the authentication logic for you.

We will create a NextJS app with an app router and integrate Nile Auth.

Create two files{" "}

'nile.ts' will expose the nile instance to the rest of the app.
'route.ts' handles the calls to Nile on the server side.

Your application will interact with the above authentication routes using SDK components. Replace the boilerplate app/page.tsx with the following code that adds signup, sign-post out, tenant selector, and user info components to your app.

With just these lines of code, you have a fully functional authentication system for your B2B app.

Why Nile Auth?

Purpose-built for multi-tenant apps

Nile re-engineers Postgres to make it easy to build and scale B2B apps. Our Auth product is also designed from the ground up to support multi-tenant applications on top of Nile's Postgres.

Auth solutions usually don’t support B2B apps, or the focus is not full-time. In Nile’s Auth case, we have designed the product for only B2B apps. Nile Auth will support the entire tenant lifecycle, including managing tenants, inviting users to tenants, overriding tenant-specific settings, tenant domains, and more.

Authenticated users can access data from any tenant they have access to - this access control is enforced at all layers - from the browser to the authentication service to the database itself. All authentication features can be enabled at the application level or disabled for a specific tenant.

Unlimited active users

One of our key focuses in developing Nile Auth was to offer the ability to support unlimited active users. Traditionally, authentication providers set a fixed limit on the number of active users, often requiring additional payments as you scale up. However, with Nile Auth, there are no extra charges for active users. You will only pay for the PostgreSQL database, allowing you to store and scale to an unlimited number of active users without incurring additional costs.

Customer and user data stored in your DB

One of the challenges we have faced with third-party auth providers is that user and customer data are locked in behind third-party APIs. There are a few issues with this approach

Referencing and joining user data with other tables in your database. It gets hard to refer to the user data using foreign key constraints or SQL joins to query across user and other business tables.
The synchronization process is async and poses consistency challenges. You could synchronize using a webhook or capture events into a changelog and apply them to the primary DB. Both approaches eventually create consistency problems. If other tables reference your application's customer or user data, users will face weird delays or could even lose data.

While Nile Postgres will integrate with third-party auth providers as well, we believe the ideal approach is to just have the Auth solution store the data in the primary DB.

There are also other benefits of building Nile Auth on Nile’s Postgres. Tenant management is not just an Auth problem. It is a data problem. Nile’s Postgres has taken a first principles approach to solving multi-tenant problems by isolating tenant data, addressing noisy neighbor problems, providing usage and cost insights by tenants, placing tenants on different compute types and regions, and supporting all the DB operations at the tenant level. Using Nile Auth and Nile’s Postgres provides a truly end-to-end solution to building and scaling B2B apps.

Comprehensive B2B auth features

Access a full suite of authentication features to secure your application thoroughly. Here are some of the features you get out of the box:

Organization management
User profiles
Dashboard for managing users and organizations
Tenant overrides - manage auth for each tenant individually
Multi-framework support - NextJS, Express, React, etc
Wide range of authentication methods - email/password, social login, magic link, etc
UI components for embedding in your application - simple, beautiful, and flexible
Cookie-Based Authentication: Secure session management using HTTP-only cookies
JWT and Session Support: Uses cookies to maintain user sessions and optionally issues JWTs for client-side validation
Single Sign-On (SSO) Support: Optional integration with external identity providers

Auth services really have to be comprehensive. Unlike other parts of the app where mixing and matching libraries and services is normal, mixing and matching two auth solutions is very challenging from a security POV - you need to keep them in sync, you need to make sure you correctly handle responses from two services, juggle multiple cookies and tokens (possibly with different expirations). Much safer to find one auth service that does everything you need and use that.

There is more on the roadmap, and our goal is to support a comprehensive list of features for B2B apps. We would love to know if you need any specific features not currently available. We also welcome community contributions.

Self-host or let Nile manage it

One of our design goals was to make it easy to self-host Nile Auth. We believe we have made it easy for developers to use our managed solution or self-host the auth service. The auth service will still use hosted Nile’s Postgres, but one can get the benefit of running core security logic within their account in the cloud. For development purposes, the entire Nile stack, including Postgres and Nile Auth, is available as a docker image. Developers can test locally and use the hosted offering when deploying to production.

Drop-in fully customizable auth UI modules

Easily integrate pre-built authentication UI modules into your application in five minutes. Add support for Google, GitHub, and more and override per-tenant. Nile’s open-source SDK includes beautiful and flexible React components that can be embedded in your application and customized to your liking. This includes the signup, login, organization switcher, user profile, social login buttons, and more.

Other design principles of Nile Auth

Support multiple languages

To truly democratize B2B authentication, we wanted to build a solution that can be leveraged with as many languages as possible. We currently support the Typescript/Javascript ecosystem but plan to support more languages. We have published our public Auth APIs and hope to provide more language coverage. We would also love the community to build and contribute SDKs for their favorite language.

Auth as a service vs a library

Auth solutions have been tackled as a service and as a library. Based on our experience, a service-first approach is the most secure solution for B2B Authentication for several reasons.

Libraries are convenient till the new CISO in a B2B company mandates that auth has to be moved to a service for security reasons. Having the auth logic across many services is usually not what CISOs want. Security teams prefer to control the authentication logic centrally.
Security hotfixes are a nightmare with thick clients. When a security hole is identified, it becomes critical for B2B companies to deploy the fix immediately. It is much easier to hotfix the central service vs upgrading the library in multiple services.
In most cases, B2B Companies need to support multiple languages from the start. For example, companies build their data plane with Typescript but their control plane using Go. Users will authenticate against both the control plane and the data plane.

We have invested in making it easy to launch and operate the Nile Auth service.

Server side authentication

Server-side authentication is a core design principle of Nile Auth, ensuring flexibility, security, and broad applicability. By focusing on server-side APIs and auto-generated routes, developers can build their own UI without being locked into a specific framework. This approach also enables authentication for API-only services, ensuring secure endpoint protection. Additionally, Nile Auth is built on strong security primitives, including Secure, HttpOnly cookies to prevent XSS, CSRF protection, and session-backed authentication instead of relying solely on JWTs. This aligns with best security practices, addressing concerns like those raised by CISOs who prioritize moving authentication logic to the backend for consistency and security across web, API, and CLI environment

Open source

We have spent years doing open-source and believe this is the right path for Nile Auth. Open source will help build trust and make Nile Auth extremely secure. It raises the bar to build a world-class service and enables the community to contribute. We want to build a developer-first community around Nile Auth and make it easy to contribute. You can look at our contributing guidelines if you are interested in adding features or fixing issues.

Try out Nile Auth today and let us know what you think! You can also join our community to discuss Nile Auth and give us feedback. We are looking forward to collaborating with the community to make this successful.

PostgreSQL re-engineered for multi-tenant apps

sriramsub — Tue, 24 Sep 2024 07:30:24 +0000

This is my first post on dev.to. We recently launched a new Postgres offering, and I wanted to share it here. Nile is a Postgres platform that decouples storage from compute, virtualizes tenants, and supports vertical and horizontal scaling globally to ship AI-native B2B applications fast while being safe with limitless scale. Nile is in public preview, and we look forward to all the feedback as we move towards GA. Sign up to Nile and try our quickstarts, or use one of our numerous AI examples or use cases.

Nile’s goal is simple - To be the best platform to build and scale multi-tenant AI applications.

We are taking a new approach to building databases that have not been attempted before. We are virtualizing the concept of a customer (or tenant) into Postgres, making Postgres and its ecosystem perfect for creating B2B AI companies. We have been working on this for the past eighteen months, and we believe it is the fastest and safest way to develop AI-native B2B applications and scale globally.

Why B2B, Why AI, and Why Postgres?

Modern relational databases have been in existence for several decades. They have undergone numerous improvements, becoming significantly faster and capable of supporting more relational features. However, the gap between the application and the database has continued to grow. There are a significant number of problems that are being tackled by B2B developers, which should be solved within the database. A general-purpose DB will always be designed to solve only the lowest common denominator and push a lot of problems unique to B2B to the application layer.

Multi-tenant architectures - can you have the cake and eat it too?

The foundation of B2B applications is a multi-tenant architecture, where each tenant typically represents a customer, workspace, organization, etc. The main challenge is how to store and query many customers/tenants in the database. Various patterns have been proposed, but there are two main approaches at a high level.

On one extreme, you can use one database per tenant. This approach has several benefits but also entails many pain points.

Benefits

Full isolation across customers, making it very difficult to leak data.
Backups, performance insights, and read replicas are all specific to each customer which is a huge advantage for low MTTR per customer.

Drawbacks

Significant cost: each database is typically deployed into its own virtual machine and has a minimum size. While you could bring the databases down when the tenants are inactive to save costs, this does not work well due to cold start time, and many tenants have low utilization (as opposed to no utilization).
Schema migration across tenants is difficult, especially when adding tenants in a self-serve manner. Deploying a new database and applying schema in a self-serve product becomes complex.
No ability to query across tenants. There is always a need to build internal customer dashboards and query across tenants for analytical purposes.
The application has to be designed to work with multiple databases, custom routing, and multiple connection pools.
Lots of tooling is needed to do fleet upgrades, metrics aggregation, alerting, and data ingestion from back-office tools into the DB.

The other extreme is to have one database across tenants.

Benefits

Simplicity. Application is designed to talk to one database and all the operational overhead for tenant per DB does not exist.
Lower cost since multiple tenants are in the same DB. You pay for one DB’s provisioned capacity.
Pretty much all the drawbacks of per DB model is a plus here

Drawbacks

Restricting access to a tenant data is not trivial. Need to enforce complex row-level security in the DB which is hard to debug or apply authorization at the application that could easily leak.
Noisy neighbor problems between tenants as some tenants grow to be active
No per-tenant query insights, backups, or read replicas that are super useful to reduce MTTR

Most companies end up having to support a hybrid approach. Companies start with one of the two approaches, and grow into the other, if successful. The reason is that as companies grow they typically have to place a subset of customers in their own database or in a particular region for compliance, isolation or latency reasons. The question is can you get all the benefits of both the architecture models without any of the downsides right from the start? Would it be possible to do this 10x cheaper and with the experience of a single database?

Building RAG apps with customer data

AI is fundamentally changing how applications are built and consumed. One of the core architectural patterns for AI apps is Retrieval Augmented Generation (RAG). This approach involves:

Calculating vector embeddings for your input dataset
Using the user's prompt to search for relevant embeddings
Finding the relevant documents or chunks within the documents
Feeding these documents along with the prompt to the Large Language Model (LLM) to get the most accurate answer

RAGs are becoming a critical part of AI infrastructure. The vector embeddings computed from customer data must be stored, queried, and scaled to millions. AI has dramatically accelerated the speed of adoption—what once took 2–3 years to reach scale is now possible in just six months. This explosion of AI adoption and the challenge of managing vector embeddings for RAG raises numerous problems.

Separate databases for vector embeddings and customer data
In recent years, numerous vector databases have emerged. This trend separates customers' core data and metadata from their embeddings, forcing companies to manage multiple databases. Such separation increases costs, significantly complicates application development and operation, and leads to inefficient resource utilization between vector embeddings and customer metadata. Moreover, keeping these databases synchronized with customer changes adds yet another layer of complexity.

Lack of isolation for customer workloads
AI workloads demand significantly more memory and compute than traditional SaaS workloads. Customer adoption and growth are much faster with AI, though some of this can be attributed to a hype cycle. Moreover, rebuilding indexes for embeddings requires additional resources and may impact production workloads. The ability to isolate customer data and their AI workloads has a significant impact on the customer's experience. Isolation is a key customer requirement (no one wants their data mixed with anyone else’s) and also critical to performance - 3 million embeddings is very large. 1000 tenants with 3000 embeddings each is very manageable - you get lower latency and 100% recall.

Scaling to billions of embeddings across customers
AI workloads scale to 50-100 million embeddings and in some cases even a billion embeddings. The biggest unlock with AI is the ability to search through unstructured data. All the data in different PDFs, Images, Wikis are now searchable. In addition, these unstructured data need to be chunked to do better contextual search. The explosion of vector embeddings requires a scalable database that can store billions of embeddings at a really low cost.

Connecting all the customer’s data to the OLTP
90% of AI use cases involve extracting data from customers' various SaaS services, making it accessible to LLMs, and allowing users to write prompts against this data. For instance, Glean, an AI-first company, aggregates data from issue trackers, wikis, and Salesforce, making it searchable in one central location using LLMs. Glean must offer a streamlined process for each customer to extract data from their SaaS APIs and transfer it to Glean's database. This data needs to be stored and managed on a per-customer basis. Vector embeddings must be computed during data ingestion. In the AI era, ETL pipelines from SaaS services to OLTP databases need to be reimagined for each customer.

Cost of computing, storing and querying customer vector embeddings
The sheer scale of vector embeddings and their associated workloads significantly increases the cost of managing AI infrastructure. The primary expenses stem from compute and storage, which typically align with customer activity. Ideally, you'd want to pay only for the exact resources a customer uses for compute. Similarly, you'd prefer cheaper storage options when embeddings aren't being accessed. By implementing per-customer cost management for their workloads, it should be possible to reduce expenses by 10 to 20 times.

Agents will create more B2B apps than humans in the next decade

Historically, the rate of application development has been constrained by human capabilities. Increasing productivity typically involved hiring more developers or implementing tools that offered modest efficiency gains of 5-10%. However, the advent of AI and the emergence of intelligent agents are set to revolutionize this landscape. We're on the brink of witnessing a surge in B2B app creation. These agent-built applications will need to select their technology stack, with databases playing a pivotal role in this process.

The main restriction to an agent world with millions of apps is database access. Currently, companies are limited by the number of databases they can have due to cost and available compute resources from cloud providers. To fundamentally change this, we need the ability to create unlimited free databases that can fully utilize available resources. This is challenging to build. It requires a true multi-tenant SQL database, rather than provisioning dedicated compute for each database or relying solely on containers or VMs. An ideal database should seamlessly move between deployments. New databases and tenants should start on serverless compute and gradually transition to provisioned compute as they grow. This approach enables a world where agents can experiment with many new applications in parallel on behalf of their users, increasing the chances of success.

Designing a Postgres platform from first principles for AI B2B apps

Customer - the atomic unit of a business

Nile aims to build Postgres from the ground up, focusing specifically on B2B AI applications. The customer or tenant is a core building block of B2B companies—everything revolves around them. It's logical, then, that a data platform built for B2B companies should have the tenant as a native primitive in the database. By defining a customer in the database and extending this concept through to the storage layer, we can address the previously discussed problems at a fundamental level, potentially reducing costs by 10–20x. This approach also simplifies customer workflows that connect to other organizations. For instance, when a premium-tier customer onboards, creating a new customer in the support platform becomes straightforward, as the database can integrate with external APIs. This eliminates the risk of losing customer activity due to failed transactions with third-party services.

Not all customers are created equal. In a typical B2B company, most customers start small and grow over time, while some become power users from the outset. Customer distribution across pricing tiers often follows a pattern: 50% inactive, 30% medium usage, and 20% power users. This distribution can vary based on the company's type and target market.

The revenue each customer brings in differs significantly. Ideally, the cost to serve a customer should reflect this variation. A B2B-focused data platform should accommodate these differences. It should incur no costs for inactive customers, charge based on utilization for medium-usage customers, and provide dedicated compute for power users.

This ability to control infrastructure costs for different customer groups enables companies to operate more efficiently. By aligning costs with customer value, businesses can optimize their resources and improve their bottom line.

Nile’s architecture

Nile has built Postgres from the ground up with tenants/customers as a core building block. The key highlights of our design are:

Decoupled storage and compute. The compute layer is essentially Postgres, modified to store each tenant's data in separate pages. The storage layer consists of a fleet of machines that house these pages. An external machine stores the log, while both the log and pages are archived in S3 for long-term storage.

Tenant-aware Postgres pages. A typical Postgres database comprises objects like tables and indexes, represented by 8KB pages. In Nile, tables are either tenant-specific or shared. Each page of a tenant table belongs exclusively to one tenant, with all records within a page associated with that tenant. This decoupled storage and tenant-dedicated page system allows for instantaneous tenant migration between different Postgres compute instances. Moving a tenant simply involves transferring tenant leadership from one compute instance to another while maintaining references to the same pages in the storage layer.

Support for both serverless and provisioned compute. The Postgres compute layer offers two types of compute. Serverless compute is built with true multitenancy, while provisioned compute is dedicated to a single Nile customer. Nile users can have any number of provisioned compute instances in the same database. Tenants can be placed on either serverless or provisioned compute.

Distributed querying across tenants and a central schema store. The distributed query layer operates across tenants and functions between serverless and provisioned compute instances. A central schema store employs distributed transactions to apply schemas to every tenant during DDL execution. This ensures correct schema application and enables schema recovery for tenants during failures.

A global gateway for tenant routing, inter-region communication, and connection pooling. The gateway uses the Postgres protocol to route requests to different tenants. It can communicate with gateways in other regions and serves as a connection pooling layer, eliminating the need for a separate pooler.

Architecture Benefits

This architecture offers numerous surprising benefits. Nile supports various multitenant configurations within a single database, giving users fine-grained control over costs at the customer level. All tenants can be placed on serverless compute for 10–20x lower costs, or a subset can be assigned to provisioned compute for enhanced isolation and security. The system seamlessly scales horizontally across tenants and vertically per tenant, providing virtually limitless capacity.

Unlimited database and virtual tenant databases
In Nile, a database is a logical concept. Our serverless compute allows us to offer a truly cost-effective, multi-tenant solution that provisions new databases rapidly. This enables Nile to provide unlimited databases, even for free tiers. Serverless compute is ideal for testing, prototyping, and supporting early customers. As customers become more active, you can seamlessly transition them to provisioned compute for enhanced security or scalability. Nile's efficiency is remarkable—a new database is provisioned in under a second.

Tenant placement on both serverless or provisioned compute with 10x compute cost savings
Tenants can now be placed on different types of compute within the same database. The serverless compute is extremely cost-efficient, proving cheaper than provisioning a standard instance on RDS. Built with true multitenancy, it enables Nile to use resources more efficiently across its users. Meanwhile, highly active customers can be moved to provisioned compute. The best part? The capacity needed for this is significantly lower than for an entire database housing all customers.

Support billions of vector embeddings across customers with 10-20x storage savings
The architecture supports vertical scaling for tenants and horizontal scaling across tenants. For vector embeddings, the total index size is divided into smaller chunks across multiple machines. Additionally, since the storage is in S3, Nile can swap a tenant’s embeddings entirely to S3 without maintaining a local cache. The indexes themselves are smaller, and multiple machines can be leveraged to build indexes in parallel. This approach provides lower latency and nearly 100% recall by reducing the search space per customer.

Secure isolation for customer’s data and embeddings
Each tenant in this architecture functions as its own virtual database. The Postgres connections understand tenants and can route to a specific one. Tenant data isolation is enforced natively in Postgres, as it recognizes tenant boundaries without the need for Row-Level Security (RLS). Furthermore, the architecture allows tenants to be moved instantly between compute instances. Performance isolation between tenants can be achieved by relocating them to other compute instances with more capacity without any downtime.

Branching, backups, query insights and read replicas by tenant/customer
Since Postgres understands tenant boundaries, we can now maintain one database for all tenants while executing database operations at the tenant level. This allows us to reproduce customer issues by simply branching the specific customer's data and replaying their workload. If a customer accidentally deletes their data, backups can be restored instantly. We can create read replicas only for customers with higher workloads, saving both compute and storage resources. Moreover, we can now debug performance for specific tenants or customers, eliminating the need to treat the database as a black box.

We are excited once again to be in public preview today. Try out Nile and build your AI B2B apps with a Postgres platform purpose built for it. We are looking forward to all the feedback!