标签：#Scaling

AWS has outlined how ProGlove, an industrial-wearables manufacturer, was able to scale its SaaS platform to run more than one million AWS Lambda functions spread across thousands of dedicated customer accounts. By Matt Foster

Multi-tenancy is the decision that quietly shapes your entire SaaS backend. Get it right and you scale smoothly to thousands of accounts. Get it wrong and you're rewriting your data layer under load, mid-growth, with customers watching. The good news: for most products the right answer is simpler than the internet suggests. The three models There are three canonical ways to isolate tenants, and they trade isolation against operational cost: Row-level (shared schema). Every table has a tenant_id\ column, and every query filters on it. One database, one schema, all tenants together. Schema-per-tenant. Each tenant gets its own PostgreSQL schema inside a shared database. Stronger isolation, more objects to manage. Database-per-tenant. Each tenant gets a dedicated database or instance. Maximum isolation, maximum operational weight. Why row-level wins for most SaaS For the overwhelming majority of B2B SaaS products, row-level multi-tenancy is the right default. It's the cheapest to operate, the easiest to run migrations against, and it scales further than founders expect. The objection is always "but isolation" — and Postgres has a strong answer. Row-Level Security (RLS) lets the database itself enforce that a query can only see its own tenant's rows. With Supabase , RLS is the native model: you set a policy once, and even a buggy query can't leak across tenants. Combined with a tenant_id\ on every table and an index that leads with it, this pattern comfortably serves large customer bases. One caution from hard experience: write RLS policies so helper functions run once per query, not once per row . A policy that re-evaluates a lookup for every row will quietly turn fast endpoints slow as tables grow. Wrap the check so the planner runs it as an init-plan. When to reach for stronger isolation Escalate deliberately, not reflexively: Regulatory or contractual isolation — a customer requires their data in a physically separate database. Noisy-neighbor risk — one whale tenant'

SaaS software vendor HubSpot has described how its semantic search platform grew from a proof of concept into an internal service that now manages more than 20 billion vectors across 38-plus teams. The company says the system now supports agents, RAG, and contact deduplication, and that the increase in agent usage has made retrieval quality and latency more important than before. By Matt Saunders

7 Things I Wish I Knew Before Scaling Next.js + Supabase to 100K Users Six months ago, we launched our SaaS with Next.js and Supabase. The stack was perfect for our MVP: fast development, great DX, and it just worked. Then we hit 10K users. Then 50K. Then 100K. Everything that worked beautifully at small scale started breaking. Database queries that took 50ms now took 5 seconds. Our Supabase bill went from $25/month to $800/month. Users complained about slow page loads. Here's what I wish someone had told me before we started. 1. RLS Policies Are Not Optional (Even in Development) We skipped RLS in development. "We'll add it before launch," we said. Launch day came. We enabled RLS on all tables. The app broke in 47 different places. Queries that worked suddenly returned empty arrays. Inserts failed with permission errors. We spent 12 hours fixing RLS policies while users waited. What I'd do differently: Enable RLS from day one. Write policies as you create tables: CREATE TABLE posts ( id UUID PRIMARY KEY DEFAULT uuid_generate_v4 (), title TEXT NOT NULL , user_id UUID REFERENCES auth . users ( id ) ); -- Enable RLS immediately ALTER TABLE posts ENABLE ROW LEVEL SECURITY ; -- Write policies now, not later CREATE POLICY "Users can view own posts" ON posts FOR SELECT USING ( auth . uid () = user_id ); Test with RLS enabled. If it works in development, it'll work in production. 2. Database Indexes Are Not Premature Optimization "We'll add indexes when we need them." We needed them on day 3. Our posts feed query went from 50ms to 8 seconds as we hit 10K posts. Users complained. We scrambled to add indexes during peak traffic. The query: const { data } = await supabase . from ( ' posts ' ) . select ( ' *, profiles(*) ' ) . eq ( ' published ' , true ) . order ( ' created_at ' , { ascending : false }) . limit ( 20 ) The fix: CREATE INDEX posts_published_created_at_idx ON posts ( published , created_at DESC ) WHERE published = true ; Query time dropped to 12ms. What I'd do di

Pinterest introduced MIQPS, a URL normalization system that identifies which query parameters affect page identity using rendered content fingerprints. It reduces duplicate processing across millions of domains by replacing rule-based approaches with offline analysis, anomaly detection, and runtime parameter maps, improving ingestion efficiency and scalability in large-scale content pipelines. By Leela Kumili