github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-31 11:26:42 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #4586] Performance issue on large organization member lists #27313

New Issue
Closed
opened 2026-04-17 18:15:04 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-17 18:15:04 -05:00
Owner
Copy Link

Originally created by @XavierGeerinck on GitHub (Sep 11, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/4586

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

When having large member lists (>10k members) in organizations, performance becomes slow due to way the listMembers and listTeamMembers (as part of https://github.com/better-auth/better-auth/pull/4582 but in analogy to listMembers) functions are implemented.

Currently they do not use JOINS but rather a 2-query approach where:

  1. They fetch the members
  2. They fetch the member details

When using a JOIN, the database would efficiently utilize existing indexes to handle this and filter out the non-required members, returning exactly and efficiently what we need.

Current vs. Expected behavior

N/A

What version of Better Auth are you using?

latest

System info

N/A

Which area(s) are affected? (Select all that apply)

Backend

Auth config (if applicable)

N/A

Additional context

No response

Originally created by @XavierGeerinck on GitHub (Sep 11, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/4586 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce When having large member lists (>10k members) in organizations, performance becomes slow due to way the `listMembers` and `listTeamMembers` (as part of https://github.com/better-auth/better-auth/pull/4582 but in analogy to `listMembers`) functions are implemented. Currently they do not use `JOINS` but rather a 2-query approach where: 1. They fetch the members 2. They fetch the member details When using a JOIN, the database would efficiently utilize existing indexes to handle this and filter out the non-required members, returning exactly and efficiently what we need. ### Current vs. Expected behavior N/A ### What version of Better Auth are you using? latest ### System info ```bash N/A ``` ### Which area(s) are affected? (Select all that apply) Backend ### Auth config (if applicable) ```typescript N/A ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-17 18:15:04 -05:00
GiteaMirror commented 2026-04-17 18:15:06 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Sep 11, 2025):

You’re right—the current implementation of listMembers and listTeamMembers uses a two-query approach: first fetching member records, then fetching user details, and joining them in memory. This design is intentional to support multiple backends (SQL, NoSQL, in-memory), but it means SQL JOINs aren’t used even when available, which leads to slow performance on large datasets see details.

There’s no architectural blocker to using JOINs in SQL-capable adapters like Prisma or Drizzle, but the current adapter abstraction doesn’t expose a JOIN-capable interface. To get JOIN performance, you’d need to either extend the adapter interface for SQL backends or implement a custom endpoint using your ORM that supports JOINs reference.

If you’re on a SQL backend and need better performance, the recommended workaround is to create a custom endpoint for member listing that uses a JOIN query. Supporting JOINs natively in Better Auth would require changes to the adapter abstraction to allow per-backend optimizations.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3281442646 --> @dosubot[bot] commented on GitHub (Sep 11, 2025): <!-- Answer --> You’re right—the current implementation of `listMembers` and `listTeamMembers` uses a two-query approach: first fetching member records, then fetching user details, and joining them in memory. This design is intentional to support multiple backends (SQL, NoSQL, in-memory), but it means SQL JOINs aren’t used even when available, which leads to slow performance on large datasets [see details](https://github.com/better-auth/better-auth/pull/3624). There’s no architectural blocker to using JOINs in SQL-capable adapters like Prisma or Drizzle, but the current adapter abstraction doesn’t expose a JOIN-capable interface. To get JOIN performance, you’d need to either extend the adapter interface for SQL backends or implement a custom endpoint using your ORM that supports JOINs [reference](https://github.com/better-auth/better-auth/issues/3779). If you’re on a SQL backend and need better performance, the recommended workaround is to create a custom endpoint for member listing that uses a JOIN query. Supporting JOINs natively in Better Auth would require changes to the adapter abstraction to allow per-backend optimizations. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/7100b96f-c1cc-4b74-91d5-09e614cc7bc4?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/4586)
GiteaMirror commented 2026-04-17 18:15:06 -05:00
Author
Owner
Copy Link

@himself65 commented on GitHub (Sep 13, 2025):

I think maybe we should have pagination API endpoint for that

<!-- gh-comment-id:3287762096 --> @himself65 commented on GitHub (Sep 13, 2025): I think maybe we should have pagination API endpoint for that
GiteaMirror commented 2026-04-17 18:15:06 -05:00
Author
Owner
Copy Link

@maulik13 commented on GitHub (Sep 14, 2025):

I second the suggestion of introducing pagination with flexible page size. However, join would still be a good option as it sounds like a low hanging fruit.

<!-- gh-comment-id:3289819067 --> @maulik13 commented on GitHub (Sep 14, 2025): I second the suggestion of introducing pagination with flexible page size. However, join would still be a good option as it sounds like a low hanging fruit.
GiteaMirror commented 2026-04-17 18:15:07 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Dec 14, 2025):

Hi, @XavierGeerinck. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary:

  • You reported a performance issue with Better Auth's handling of large organization member lists due to a two-query approach instead of using SQL JOINs.
  • The current design supports multiple backends, which complicates direct JOIN usage.
  • The maintainer acknowledged that JOINs could improve SQL backend performance if the adapter interface were extended.
  • Other users suggested adding pagination endpoints as a practical improvement alongside considering JOIN optimizations.
  • The issue remains unresolved, balancing backend flexibility with query efficiency.

Next Steps:

  • Please let me know if this issue is still relevant with the latest version of better-auth by commenting here to keep the discussion open.
  • Otherwise, I will automatically close this issue in 7 days.

Thanks for your understanding and contribution!

<!-- gh-comment-id:3651584744 --> @dosubot[bot] commented on GitHub (Dec 14, 2025): Hi, @XavierGeerinck. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary:** - You reported a performance issue with Better Auth's handling of large organization member lists due to a two-query approach instead of using SQL JOINs. - The current design supports multiple backends, which complicates direct JOIN usage. - The maintainer acknowledged that JOINs could improve SQL backend performance if the adapter interface were extended. - Other users suggested adding pagination endpoints as a practical improvement alongside considering JOIN optimizations. - The issue remains unresolved, balancing backend flexibility with query efficiency. **Next Steps:** - Please let me know if this issue is still relevant with the latest version of better-auth by commenting here to keep the discussion open. - Otherwise, I will automatically close this issue in 7 days. Thanks for your understanding and contribution!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#27313
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?