We have over seventeen systems running in production across LATAM. Some are electronic invoicing SaaS platforms processing tens of thousands of transactions per day. Others are internal management platforms for companies with thousands of concurrent users. Some we built from scratch; others came to us with scaling problems, accumulated technical debt, or architectures that once seemed reasonable and over time became the bottleneck for the entire business.
The most consistent lesson across all those projects is this: the architecture decisions made in the first weeks of a project are what you pay for — or celebrate — in year two. Not the technology itself. Not the chosen framework. The structural decisions: how code is organized, how data is isolated between clients, how consistency is managed, where business logic lives. This article documents the patterns that work in real production and the antipatterns we've seen cost millions of dollars in rework.
The most expensive mistake: over-engineering the MVP
One of the most common patterns we've seen in the last three years: the technical team, with the best intentions, designs a distributed microservices architecture from day one. Independent services for authentication, notifications, billing, analytics. Message queues with RabbitMQ or Kafka. Containers orchestrated with Kubernetes in production. An infrastructure worthy of a system processing tens of millions of events per day. The problem: when they launched, they had 87 registered users, 12 of whom were the company's own team. Their runway was six months.
We've seen MVPs with budgets of $150,000 to $200,000 USD fail because the architecture was designed for a scale the business never reached — not because the market didn't exist, but because time and capital were consumed building infrastructure plumbing instead of validating whether the product solved a real problem. The operational complexity of microservices multiplies development costs, debugging times, and the onboarding curve for every new developer joining the team.
The most illustrative case we can cite: an HR SaaS startup that spent six months building a microservices architecture before having a single paying customer. After analyzing the situation together, they decided to rewrite everything as a modular monolith — a well-structured monolith with clear bounded contexts, decoupled modules, and well-defined interfaces between domains. They launched in six additional weeks. Today they have three thousand active users and the monolithic architecture is still perfectly manageable. Service extraction will happen when it's necessary — when they have a module with a dedicated team, real independent deploy cycles, and clearly distinct scaling requirements. Not before.
Practical rule we apply on every project: extract a service when you have a measurable scaling problem that the monolith cannot solve reasonably. Not because "that's how Netflix does it". Netflix has thousands of engineers to manage that complexity. You have four.
Multi-tenancy: the three real options
Multi-tenant architecture is the heart of any B2B SaaS. The way you separate — or don't separate — your clients' data has implications that go from security and compliance to infrastructure costs, migration complexity, and the sales conversation with enterprise clients who ask to see your data architecture before signing. There is no universally correct option. There is the correct option for your market segment, your stage, and your regulatory requirements.
| Strategy | Isolation | Infra cost | Complexity | Best for |
|---|---|---|---|---|
| Shared DB, shared schema Row-level with tenant_id | Low | Very low | Simple | SMB, non-compliance tools |
| Shared DB, separate schema One schema per tenant in same DB | Medium-high | Low-medium | Moderate | Mid-market B2B, optimal balance |
| Separate DB per tenant Dedicated instance per client | Total | High | High | Enterprise, healthcare, finance |
The first option — shared database with shared schema, using a tenant_id column in each table for logical isolation — is the simplest and most economical. All isolation logic lives in the application layer: every query must include the tenant filter. The problem is that this requires absolute discipline. A poorly written query, a join that forgets the filter, an analytics function that scans the entire table without discriminating — and you have a data leak between clients. It's suitable for products targeting SMB segments where clients don't have legal teams reviewing your security architecture, and where per-tenant data volume is low enough that composite indexes on tenant_id maintain performance.
The second option — shared database with separate schemas per tenant within the same PostgreSQL instance — is the middle ground we most recommend for mid-market B2B SaaS. Each client has their own schema with their own set of tables. Data isolation is real and verifiable: a query in one tenant's schema cannot access another's data at the database level, regardless of what the application code does. The main complexity is in migrations: when you update the schema, you have to apply it to all tenants in a coordinated way. This requires a well-designed per-tenant migration system, but the benefit in terms of client trust — and in sales conversations with midsize companies that ask about data separation — clearly justifies it.
The third option — a completely separate database instance per client — is the only acceptable architecture when selling to enterprise with compliance requirements like SOC 2 Type II, ISO 27001, HIPAA, or financial and healthcare sector regulations. The operational cost rises considerably: you pay database infrastructure multiplied by the number of clients, maintenance complexity grows exponentially, and each migration is a large-scale coordinated operation. But the ability to demonstrate to an enterprise CISO that their data is physically isolated from all other clients is, in that segment, a non-negotiable requirement that closes or loses six-figure annual contracts.
PostgreSQL as the foundation — and when to add Redis and MongoDB
PostgreSQL solves 95% of B2B SaaS use cases with correct indexing and a well-designed data model. It's ACID-compliant, handles native JSON with jsonb when you need schema flexibility in specific parts of the system, has mature extensions for full-text search (pg_trgm), vectors for semantic search (pgvector), and geospatial data (PostGIS). Its performance under B2B transactional loads is robust up to volumes that most LATAM SaaS products will never reach in their first three years. The rule is simple: start with PostgreSQL and add complexity only when you have a measurable, documented performance problem that Postgres cannot reasonably solve.
Redis enters when you need speed in operations that don't require full durability. Use cases where Redis genuinely changes the equation: user session storage (sub-millisecond authentication queries), rate limiting by IP or API key, pub/sub for real-time notifications and dashboard updates without constant polling, and caching of expensive query results with well-defined TTLs. Redis latency is in the microseconds range — orders of magnitude less than a round-trip to PostgreSQL. But Redis is a complementary tool, not a replacement. Your source of truth remains Postgres.
MongoDB makes sense when your data model is genuinely document-oriented: structures that vary significantly between records, deeply nested data that would change the relational schema too frequently, or semi-structured content that is fundamentally different in nature from transactional data. What definitely doesn't make sense is using MongoDB as a PostgreSQL substitute because "it's faster" or "more flexible at the start." That decision silently accumulates technical debt: you lose ACID guarantees on multi-document operations, foreign keys and referential integrity at the database level, and PostgreSQL's mature ecosystem of analysis and administration tools.
Warning on premature optimization: we've audited codebases with Redis, Elasticsearch and MongoDB implemented from day one — before having a thousand users — because "it's more scalable that way." Complex infrastructure has a real, measurable cost in development time, debugging, operational costs, and the onboarding curve for new engineers. Measure first. Add complexity when you have evidence that you need it, not in anticipation.
The N+1 query problem
The N+1 query is the most frequent performance problem we find when auditing B2B SaaS codebases, and it's invisible until it isn't. The classic scenario: you have a screen showing a list of 100 companies. For each company, the code makes a separate query to fetch its active contracts. Result: 101 database queries instead of 2. In local development with ten test records, this goes unnoticed. In production with real data, this difference can be between 200ms and 12 seconds of load time on a screen the sales team uses in every prospect demo.
The problem is that modern ORMs — Prisma, Sequelize, SQLAlchemy, ActiveRecord — hide this antipattern brilliantly. The code looks clean, semantic, and expressive. What it's executing on the database is the opposite. The fundamental tool for detecting it is activating query logging in the development environment and actively reviewing whether you see the same type of query executing repeatedly in sequence. Any number above 20 queries per request on a listing endpoint should be an immediate investigation trigger. The solutions are well-established: eager loading — loading relationships in the same initial query using joins or includes — is the most direct remedy. For GraphQL APIs, the DataLoader pattern batches and deduplicates queries in the same execution cycle, eliminating the problem systematically.
Deployment in LATAM — AWS São Paulo vs us-east-1
Network latency is a user experience factor rarely considered in early architecture stages, and expensive to change later. The difference between us-east-1 (Virginia) and sa-east-1 (São Paulo) for a user in Lima, Bogotá or Santiago is concrete: approximately 150-200ms RTT from Lima to us-east-1, versus 40-60ms to sa-east-1. For highly interactive applications — dashboards with frequent updates, forms with real-time validation, collaboration tools — that 100-160ms difference accumulates on every interaction and the perceived experience is noticeably slower.
The cost of sa-east-1 is approximately 20% higher than us-east-1 for equivalent services. That extra cost is justified when most of your users are in South America and your product has frequent low-latency interactions. For early-stage projects where operational cost is critical, platforms like Railway, Render or Fly.io offer simple deployment in regions with acceptable latency from LATAM at significantly lower prices than managing your own infrastructure on AWS.
The monitoring you can't skip
A production system without monitoring is a system that fails silently until a client writes at 9am Monday reporting that they've been locked out for four hours. Monitoring is not a future improvement you add "when you have time" — it's part of the system architecture, as important as the database or authentication system. The minimum layer every production B2B SaaS needs has four components: error tracking to capture exceptions in frontend and backend with full context, uptime monitoring with checks every one or two minutes that alert the team before a client does, basic APM to measure response times per endpoint and identify performance regressions, and structured logging with correlation IDs that let you trace an operation across multiple system components.
The stack we recommend by cost-effectiveness ratio for SaaS in growth stage in LATAM: Sentry for error tracking in frontend and backend. Uptime Robot or Better Uptime for availability monitoring with Slack and SMS alerts. For APM, Datadog or New Relic when the team grows and you need distributed tracing. The most important metric to actively monitor: the p95 percentile of response time on your critical endpoints. If your p95 exceeds 2 seconds, you have a problem your users are noticing even if they don't tell you.
Conclusion
The architecture decisions you make in the first months of a SaaS largely determine how fast you can iterate, how much it costs to operate the system, and how hard it will be to scale when scaling time comes. There is no universally correct architecture — there is the correct architecture for your current stage, current team, and current user base. Start simple. Measure everything. Add complexity only when you have concrete evidence that you need it. And when that moment comes, the complexity you add should solve a specific, measurable problem — not an anticipation of hypothetical problems that may never arrive.