--- title: Multi-Tenant Best Practices Can Backfire | daily.dev description: Multi-tenant best practices like tenant context, global query filters, database-per-tenant, and feature flags don't eliminate complexity—they just relocate it.... canonical: https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Multi-Tenant Best Practices Can Backfire | daily.dev og:description: Multi-tenant best practices like tenant context, global query filters, database-per-tenant, and feature flags don't eliminate complexity—they just relocate it.... og:url: https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba og:image: https://api.daily.dev/og/posts/fjWaU1JBA.png og:image:alt: Multi-Tenant Best Practices Can Backfire og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Multi-Tenant Best Practices Can Backfire **[CodeOpinion](https://daily.dev/sources/codeopinion)** · [@codeopinion](https://daily.dev/codeopinion) · 10 min read · 88 upvotes · 6 comments ## Summary Multi-tenant best practices like tenant context, global query filters, database-per-tenant, and feature flags don't eliminate complexity—they just relocate it. The piece walks through a real bug where an implicit tenant context built for HTTP requests failed to carry over correctly into a background message-processing context, causing a request meant for tenant A to execute for tenant B. It then examines tradeoffs across explicit vs. implicit tenant identity, shared vs. per-tenant databases, and feature flags vs. modular codebases, arguing developers should ask what complexity they're trading rather than seeking a single correct pattern. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### why would a background job process the wrong tenant's data even though my HTTP request handling looks correct An implicit tenant context built during an HTTP request does not automatically carry over when a message is picked up by a separate background process. If the tenant context is rebuilt incorrectly from queue message data, the background job can silently execute for the wrong tenant with no exceptions or errors logged, since the tenant identity was hidden rather than passed explicitly. _daily.dev surfaces architecture writeups like this for teams debugging cross-context tenant isolation bugs._ ### should I use a shared database with global query filters or a database per tenant for multi-tenancy Neither removes complexity, it only relocates it. A shared database with global query filters or row-level security gives safer default isolation but requires an escape hatch for cross-tenant operations like reporting, which introduces risky exceptions. A database per tenant avoids that leakage risk but forces you to query each database individually or build separate aggregation for analytics. _Developers weighing database isolation strategies can compare these tradeoffs further on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@ristotoldsep** · 4 upvotes > Implicit tenant context is convenient until tenant B receives tenant A’s surprise package. **@ahmetozel** · 2 upvotes > The invoice message crossing from an HTTP request into a worker is the boundary I would make explicit, even if tenant context remains convenient inside each process. A worker should reconstruct its context from a validated message envelope and reject a missing tenant instead of inheriting any ambient value. > > A useful regression alternates tenant A and B jobs on the same worker, including a failed job followed by another tenant’s retry. That exposes context leakage across reused execution paths. The database-per-tenant version still needs this check: selecting the wrong connection can silently... **@qinisom** · 0 upvotes > Now it makes sense why I keep getting invoiced by a company I've never interacted with. **@eliasdevv** · 0 upvotes > implicit tenant context is a race condition waiting to happen, how do you guarantee the filter propagates across async workers without adding a synchronous hop that kills throughput ## Similar posts on daily.dev - [Multi-Tenant vs. Single-Tenant: The Architecture Decision That Shapes Everything Else](https://daily.dev/posts/multi-tenant-vs-single-tenant-the-architecture-decision-that-shapes-everything-else-2ssiyblqp) · Medium · 7 upvotes · 0 comments - [Why I prefer multi-tenant systems](https://daily.dev/posts/why-i-prefer-multi-tenant-systems-gratprt4l) · Advanced Web Machinery · 95 upvotes · 4 comments - [Tenant Isolation in Multi-Tenant Systems: Architecture, Identity, and Security](https://daily.dev/posts/tenant-isolation-in-multi-tenant-systems-architecture-identity-and-security-epsekbshh) · Security Boulevard · 1 upvotes · 0 comments - [Beyond tenant\_id: Treating Multi-Tenancy as a Database Invariant](https://daily.dev/posts/beyond-tenant-id-treating-multi-tenancy-as-a-database-invariant-dpssptbwc) · RUBYLAND · 10 upvotes · 0 comments --- Tags: [#architecture](https://daily.dev/tags/architecture), [#database](https://daily.dev/tags/database), [#multi-tenancy](https://daily.dev/tags/multi-tenancy) [View this post on daily.dev](https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Multi-Tenant Best Practices Can Backfire","url":"https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba"},"datePublished":"2026-10-04T13:07:54.230Z","dateModified":"2026-10-05T10:00:17.807Z","description":"Multi-tenant best practices like tenant context, global query filters, database-per-tenant, and feature flags don't eliminate complexity—they just relocate it....","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bbf3ebb2a1127728d3d490a948939068?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/bbf3ebb2a1127728d3d490a948939068?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"CodeOpinion","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Person","name":"Derek Comartin","url":"https://daily.dev/codeopinion","image":"https://lh3.googleusercontent.com/a-/AOh14GgoQapb7NmLN1TZ6L-UCxkRpDZ4H7LKwud1DUZCTSI=s100","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":950}},"commentCount":6,"discussionUrl":"https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":88},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":6}],"keywords":"architecture,database,multi-tenancy","timeRequired":"PT10M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"CodeOpinion","item":"https://daily.dev/sources/codeopinion"},{"@type":"ListItem","position":3,"name":"Multi-Tenant Best Practices Can Backfire"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba","comment":[{"@type":"Comment","text":"Implicit tenant context is convenient until tenant B receives tenant A’s surprise package.","datePublished":"2026-10-06T10:10:54.661Z","url":"https://daily.dev/posts/fjWaU1JBA#c-mDwSToOC6","author":{"@type":"Person","name":"Risto Tõldsep","url":"https://daily.dev/ristotoldsep","image":"https://lh3.googleusercontent.com/a/ACg8ocLDWc6mZn0JwNmXXw6WY0L_HJ6pegzRttooC5VgtXESHSj3MNYx=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4}},{"@type":"Comment","text":"The invoice message crossing from an HTTP request into a worker is the boundary I would make explicit, even if tenant context remains convenient inside each process. A worker should reconstruct its context from a validated message envelope and reject a missing tenant instead of inheriting any ambient value.\nA useful regression alternates tenant A and B jobs on the same worker, including a failed job followed by another tenant’s retry. That exposes context leakage across reused execution paths. The database-per-tenant version still needs this check: selecting the wrong connection can silently execute a perfectly valid query against the wrong tenant’s database.","datePublished":"2026-10-06T18:19:40.020Z","url":"https://daily.dev/posts/fjWaU1JBA#c-FI9Kgs114","author":{"@type":"Person","name":"Ahmet Özel","url":"https://daily.dev/ahmetozel","image":"https://avatars.githubusercontent.com/u/70992231?v=4"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":2}},{"@type":"Comment","text":"Now it makes sense why I keep getting invoiced by a company I’ve never interacted with.","datePublished":"2026-10-08T17:03:14.001Z","url":"https://daily.dev/posts/fjWaU1JBA#c-VwMIwDkdI","author":{"@type":"Person","name":"Qiniso","url":"https://daily.dev/qinisom","image":"https://lh3.googleusercontent.com/a/ACg8ocLzPMQzMVgYRd3ss9UD_Qwtl39vy5wXHIirliQ5DyW9cTGdq08=s96-c"}},{"@type":"Comment","text":"implicit tenant context is a race condition waiting to happen, how do you guarantee the filter propagates across async workers without adding a synchronous hop that kills throughput","datePublished":"2026-10-10T18:21:26.299Z","url":"https://daily.dev/posts/fjWaU1JBA#c-BPDmoRmE9","author":{"@type":"Person","name":"elias-devv","url":"https://daily.dev/eliasdevv","image":"https://avatars.githubusercontent.com/u/338986921?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/multi-tenant-best-practices-can-backfire-fjwau1jba#faq","mainEntity":[{"@type":"Question","name":"why would a background job process the wrong tenant's data even though my HTTP request handling looks correct","acceptedAnswer":{"@type":"Answer","text":"An implicit tenant context built during an HTTP request does not automatically carry over when a message is picked up by a separate background process. If the tenant context is rebuilt incorrectly from queue message data, the background job can silently execute for the wrong tenant with no exceptions or errors logged, since the tenant identity was hidden rather than passed explicitly. daily.dev surfaces architecture writeups like this for teams debugging cross-context tenant isolation bugs."}},{"@type":"Question","name":"should I use a shared database with global query filters or a database per tenant for multi-tenancy","acceptedAnswer":{"@type":"Answer","text":"Neither removes complexity, it only relocates it. A shared database with global query filters or row-level security gives safer default isolation but requires an escape hatch for cross-tenant operations like reporting, which introduces risky exceptions. A database per tenant avoids that leakage risk but forces you to query each database individually or build separate aggregation for analytics. Developers weighing database isolation strategies can compare these tradeoffs further on daily.dev."}}]} ```