github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-23 07:18:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #5415] Add benchmarks to track performance #18868

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

Originally created by @igoforth on GitHub (Oct 19, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/5415

Is this suited for github?

  • Yes, this is suited for github

Is your feature request related to a problem? Please describe.

Better Auth is a feature-rich framework that works out-of-the-box in many environments. Better Auth does not yet have any way to benchmark performance such as cold start or requests/second. It's important to have benchmarks to help developers understand the impact of their latest commits, help integrators determine which endpoints are faster or slower than others, and help the community compare the performance of open source projects.

Describe the solution you'd like

A good first step is to measure cold-start performance and requests/second (rps). Because each endpoint is different, hooks can be used to perform any setup or teardown (e.g. signing up before benching the /sign-in/email endpoint). The solution shouldn't measure unnecessary overhead like betterAuth(), getTestInstance(), or network overhead in the case of rps, but should measure any deferred loading before the first request returns a response in the case of cold starts (like await $context). In the future an ideal solution would measure concurrent rps using tasks, but for now sequential rps (awaiting the current response before sending the next request) works fine.

Describe alternatives you've considered

There aren't many good options. You could measure the time it takes for tests to complete. But users shouldn't have to measure in edge environments where they're charged per request.

Additional context

I have a working implementation I'll submit in a pull request if this is something worth pursuing.

Originally created by @igoforth on GitHub (Oct 19, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/5415 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Better Auth is a feature-rich framework that works out-of-the-box in many environments. Better Auth does not yet have any way to benchmark performance such as cold start or requests/second. It's important to have benchmarks to help developers understand the impact of their latest commits, help integrators determine which endpoints are faster or slower than others, and help the community compare the performance of open source projects. ### Describe the solution you'd like A good first step is to measure cold-start performance and requests/second (rps). Because each endpoint is different, hooks can be used to perform any setup or teardown (e.g. signing up before benching the /sign-in/email endpoint). The solution shouldn't measure unnecessary overhead like `betterAuth()`, `getTestInstance()`, or network overhead in the case of rps, but should measure any deferred loading before the first request returns a response in the case of cold starts (like `await $context`). In the future an ideal solution would measure concurrent rps using tasks, but for now sequential rps (awaiting the current response before sending the next request) works fine. ### Describe alternatives you've considered There aren't many good options. You could measure the time it takes for tests to complete. But users shouldn't have to measure in edge environments where they're charged per request. ### Additional context I have a working implementation I'll submit in a pull request if this is something worth pursuing.
GiteaMirror added the lockedenhancement labels 2026-04-15 17:33:22 -05:00
GiteaMirror commented 2026-04-15 17:33:24 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Nov 4, 2025):

The performance bottlenecks of better-auth comes primarily from database speeds as well as framework performance.
req/sec changes from framework to framework, the actual better-auth logic itself are all practically synchronous. 9 times out of 10 where I see performance drops is when there is a slow database connection, if the database were able to return a response instantly then all basically all better-auth endpoints run in equal speed, very very few milliseconds difference as everything is almost synchronous.

The few exceptions to this being if the endpoint needs to make fetch requests to outside endpoints (determined by network speed) or if it's performing cryptographic calculations such as hashing a password (determined by CPU speed).

But for the most part, performance variations are far to inconsistent between database providers, ORMs, network & CPU speeds as well as framework performance.
If we removed all of those factors and purely calculated better-auth performance, I believe they're probably under 1ms unless the few exceptions I stated earlier apply.

With most endpoints being that fast, I don't think it makes much sense to have a benchmark as there isn't much to benchmark...

It would probably make more sense to have a system to allow our users to benchmark their setup with Better-Auth then it is to benchmark better-auth as it is. As most of the performance bottleneck comes from things outside of better-auth's control (DB speed, framework, etc etc) after all.

<!-- gh-comment-id:3486818257 --> @ping-maxwell commented on GitHub (Nov 4, 2025): The performance bottlenecks of better-auth comes primarily from database speeds as well as framework performance. req/sec changes from framework to framework, the actual better-auth logic itself are all practically synchronous. 9 times out of 10 where I see performance drops is when there is a slow database connection, if the database were able to return a response instantly then all basically all better-auth endpoints run in equal speed, very very few milliseconds difference as everything is almost synchronous. The few exceptions to this being if the endpoint needs to make fetch requests to outside endpoints (determined by network speed) or if it's performing cryptographic calculations such as hashing a password (determined by CPU speed). But for the most part, performance variations are far to inconsistent between database providers, ORMs, network & CPU speeds as well as framework performance. If we removed all of those factors and purely calculated better-auth performance, I believe they're probably under 1ms unless the few exceptions I stated earlier apply. With most endpoints being that fast, I don't think it makes much sense to have a benchmark as there isn't much to benchmark... It would probably make more sense to have a system to allow our users to benchmark their setup with Better-Auth then it is to benchmark better-auth as it is. As most of the performance bottleneck comes from things outside of better-auth's control (DB speed, framework, etc etc) after all.
GiteaMirror commented 2026-04-15 17:33:25 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Nov 4, 2025):

(tag @better-auth-agent)

Hi there! Thanks for opening this issue. Based on your description, it seems that the current performance discrepancies are primarily due to external factors such as database speeds, framework overhead, network latency, and CPU performance during cryptographic operations rather than any significant inefficiency in Better Auth's core logic. In essence, most endpoints perform nearly synchronously—with most core operations executing in under 1ms when external delays are minimal.

Given this, a benchmark that isolates Better Auth itself might not provide significant insights since the variability comes largely from the surrounding environment. Instead, it might be more beneficial to offer benchmarking tools that allow users to measure their entire setup's performance, including their specific database, ORM, and framework choices.

For next steps, you could:

  1. Open a pull request with your working implementation to provide sequential benchmarks for cold starts and requests per second.
  2. Consider adding configuration options so that advanced users could opt to benchmark only the Better Auth-specific parts if necessary.
  3. Discuss with the community (e.g., by tagging @bekacru or @ping__) to gather further ideas and ensure this approach aligns with the project's goals [1][2].

Does this align with your understanding, or would you like to explore other approaches for integrating such benchmarks further?

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3486841919 --> @better-auth-agent[bot] commented on GitHub (Nov 4, 2025): (tag @better-auth-agent) Hi there! Thanks for opening this issue. Based on your description, it seems that the current performance discrepancies are primarily due to external factors such as database speeds, framework overhead, network latency, and CPU performance during cryptographic operations rather than any significant inefficiency in Better Auth's core logic. In essence, most endpoints perform nearly synchronously—with most core operations executing in under 1ms when external delays are minimal. Given this, a benchmark that isolates Better Auth itself might not provide significant insights since the variability comes largely from the surrounding environment. Instead, it might be more beneficial to offer benchmarking tools that allow users to measure their entire setup's performance, including their specific database, ORM, and framework choices. For next steps, you could: 1. Open a pull request with your working implementation to provide sequential benchmarks for cold starts and requests per second. 2. Consider adding configuration options so that advanced users could opt to benchmark only the Better Auth-specific parts if necessary. 3. Discuss with the community (e.g., by tagging @bekacru or @ping__) to gather further ideas and ensure this approach aligns with the project's goals [[1]](https://github.com/better-auth/better-auth/issues/5415)[[2]](https://github.com/better-auth/better-auth/issues/4125). Does this align with your understanding, or would you like to explore other approaches for integrating such benchmarks further? <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 17:33:25 -05:00
Author
Owner
Copy Link

@igoforth commented on GitHub (Nov 4, 2025):

@ping-maxwell Thanks for the reply.

It makes sense why there's been a big push to standardize database testing in better-auth.

What database are you guys planning on using for Infrastructure?

I see req/sec halve between /ok and /sign-out using sqlite. The difference being /sign-out has getSignedCookie() and internalAdapter.deleteSession(). That's only latency though. I think benchmarks would reveal if the database is the bottleneck once you start hammering parallel requests. To push /ok performance further as you said would be framework performance. Image here https://github.com/better-auth/better-auth/pull/5416#issue-3530275428

There are opportunities to make getAdapter() synchronous by pushing kysely promise resolution to the first call. I don't know the effectiveness yet. But it opens a path to making all of init() synchronous and could make initial response time faster for endpoints which don't use the database if you're willing to rollback async for BetterAuthPlugin.init() and get creative with createTelemetry()

// in db/utils.ts
kyselyAdapter(
	adapter.initialize
		? adapter.initialize().then(checkKysely)
		: checkKysely(),
	{
		type: adapter.databaseType ?? "sqlite",
		debugLogs:
			"debugLogs" in options.database! ? options.database.debugLogs : false,
		transaction: adapter.transaction,
	},
)(options)

// in adapters/kysely-adapter/kysely-adapter.ts
const kyselyAdapter = (
	db: Kysely<any> | Promise<Kysely<any>>,
	config?: KyselyAdapterConfig,
) => {
	// ...
	return {
		create: ({ data, model }) =>
			// awaits db if promise
			withDb(async (db) => {
				const builder = db.insertInto(model).values(data);
				const returned = await withReturning(data, builder, model, []);
				return returned;
			})
		// ...
	}
}

The main idea I arrived at unintentionally with the pull request is to be able to compare benchmarks from pull requests to upstream to catch performance regressions. Would love to get your thoughts on that. https://github.com/better-auth/better-auth/pull/5416

Giving users a way to benchmark their setup would be helpful. The only nit being if they host serverless. Is more integration with serverless environments on the Better Auth roadmap?

<!-- gh-comment-id:3487268577 --> @igoforth commented on GitHub (Nov 4, 2025): @ping-maxwell Thanks for the reply. It makes sense why there's been a big push to standardize database testing in better-auth. What database are you guys planning on using for Infrastructure? I see req/sec halve between `/ok` and `/sign-out` using sqlite. The difference being `/sign-out` has `getSignedCookie()` and `internalAdapter.deleteSession()`. That's only latency though. I think benchmarks would reveal if the database is the bottleneck once you start hammering parallel requests. To push `/ok` performance further as you said would be framework performance. Image here https://github.com/better-auth/better-auth/pull/5416#issue-3530275428 There are opportunities to make `getAdapter()` synchronous by pushing kysely promise resolution to the first call. I don't know the effectiveness yet. But it opens a path to making all of `init()` synchronous and could make initial response time faster for endpoints which don't use the database if you're willing to rollback async for `BetterAuthPlugin.init()` and get creative with `createTelemetry()` ```typescript // in db/utils.ts kyselyAdapter( adapter.initialize ? adapter.initialize().then(checkKysely) : checkKysely(), { type: adapter.databaseType ?? "sqlite", debugLogs: "debugLogs" in options.database! ? options.database.debugLogs : false, transaction: adapter.transaction, }, )(options) ``` ```typescript // in adapters/kysely-adapter/kysely-adapter.ts const kyselyAdapter = ( db: Kysely<any> | Promise<Kysely<any>>, config?: KyselyAdapterConfig, ) => { // ... return { create: ({ data, model }) => // awaits db if promise withDb(async (db) => { const builder = db.insertInto(model).values(data); const returned = await withReturning(data, builder, model, []); return returned; }) // ... } } ``` The main idea I arrived at unintentionally with the pull request is to be able to compare benchmarks from pull requests to upstream to catch performance regressions. Would love to get your thoughts on that. https://github.com/better-auth/better-auth/pull/5416 Giving users a way to benchmark their setup would be helpful. The only nit being if they host serverless. Is more integration with serverless environments on the Better Auth roadmap?
GiteaMirror commented 2026-04-15 17:33:26 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Nov 4, 2025):

Hi there, thanks for the detailed insights! It sounds like you’re proposing to integrate CI benchmarks that compare performance (including cold starts and rps) across endpoints and even against upstream changes. This approach would not only monitor performance regressions but also shed some light on whether database latency (for instance, the synchronous conversion of getAdapter) or framework overhead is the main bottleneck [1].

Regarding the database, if you’re noticing a significant drop between endpoints like /ok and /sign-out due to calls such as getSignedCookie() or internalAdapter.deleteSession(), it would be worth testing under both serverful and serverless configurations to see which part of the stack contributes more to the slowdown. We do have plans to explore more integration for serverless environments, so any benchmarks that target that area would be valuable too [1].

Next steps could be:
• Integrate these benchmarks into your CI, using hooks for endpoint-specific setups and teardowns.
• Compare sequential versus potential concurrent approaches for rps tests.
• Specifically target endpoints with additional overhead (like /sign-out) to see if optimizing adapter initialization (perhaps making getAdapter synchronous) can improve latency.
• Experiment in both sqlite and other database setups if possible, to identify if the database is indeed the performance bottleneck.

Does this align with your initial expectations for the benchmark suite, or are there additional areas you’re interested in investigating further? tag @better-auth-agent

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3487271173 --> @better-auth-agent[bot] commented on GitHub (Nov 4, 2025): Hi there, thanks for the detailed insights! It sounds like you’re proposing to integrate CI benchmarks that compare performance (including cold starts and rps) across endpoints and even against upstream changes. This approach would not only monitor performance regressions but also shed some light on whether database latency (for instance, the synchronous conversion of getAdapter) or framework overhead is the main bottleneck [[1]](https://github.com/better-auth/better-auth/issues/5415). Regarding the database, if you’re noticing a significant drop between endpoints like /ok and /sign-out due to calls such as getSignedCookie() or internalAdapter.deleteSession(), it would be worth testing under both serverful and serverless configurations to see which part of the stack contributes more to the slowdown. We do have plans to explore more integration for serverless environments, so any benchmarks that target that area would be valuable too [[1]](https://github.com/better-auth/better-auth/issues/5415). Next steps could be: • Integrate these benchmarks into your CI, using hooks for endpoint-specific setups and teardowns. • Compare sequential versus potential concurrent approaches for rps tests. • Specifically target endpoints with additional overhead (like /sign-out) to see if optimizing adapter initialization (perhaps making getAdapter synchronous) can improve latency. • Experiment in both sqlite and other database setups if possible, to identify if the database is indeed the performance bottleneck. Does this align with your initial expectations for the benchmark suite, or are there additional areas you’re interested in investigating further? tag @better-auth-agent <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 17:33:27 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Nov 4, 2025):

(tag @better-auth-agent)

Hi there! I appreciate the detailed performance analysis and your insights on potential optimizations, including the idea of making initialization synchronous to reduce cold-start latency. Currently, we're exploring benchmarks not only to compare pull request performance but also to help users understand how configuration choices—such as database adapter selection or caching strategies—affect latency under load [1].

As for your question about our infrastructure, for our internal benchmarking and stability tests we predominantly use SQLite during early-stage development, but we also run tests against PostgreSQL (via Kysely) to simulate production environments, particularly in serverless contexts where latency differences could be more pronounced. Regarding greater integration with serverless environments, it's an area we’re actively investigating and consider a key focus for future releases [2].

Would you be open to sharing further results from your benchmarking experiments? Your feedback is invaluable to ensure our roadmap aligns with community needs. Let me know your thoughts!

tag @better-auth-agent

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3487309206 --> @better-auth-agent[bot] commented on GitHub (Nov 4, 2025): (tag @better-auth-agent) Hi there! I appreciate the detailed performance analysis and your insights on potential optimizations, including the idea of making initialization synchronous to reduce cold-start latency. Currently, we're exploring benchmarks not only to compare pull request performance but also to help users understand how configuration choices—such as database adapter selection or caching strategies—affect latency under load [[1]](https://github.com/better-auth/better-auth/issues/5415). As for your question about our infrastructure, for our internal benchmarking and stability tests we predominantly use SQLite during early-stage development, but we also run tests against PostgreSQL (via Kysely) to simulate production environments, particularly in serverless contexts where latency differences could be more pronounced. Regarding greater integration with serverless environments, it's an area we’re actively investigating and consider a key focus for future releases [[2]](https://github.com/better-auth/better-auth/issues/4125). Would you be open to sharing further results from your benchmarking experiments? Your feedback is invaluable to ensure our roadmap aligns with community needs. Let me know your thoughts! tag @better-auth-agent <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
GiteaMirror commented 2026-04-15 17:33:28 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Jan 8, 2026):

For now it doesn't make sense to have benchmarks in Better Auth as it's primarily outside factors which slow things down, I'm going to close this for now. For other ideas such as having a user-ran benchmark maybe that could be it's own issue, separate to this.

<!-- gh-comment-id:3724165700 --> @ping-maxwell commented on GitHub (Jan 8, 2026): For now it doesn't make sense to have benchmarks in Better Auth as it's primarily outside factors which slow things down, I'm going to close this for now. For other ideas such as having a user-ran benchmark maybe that could be it's own issue, separate to this.
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 enhancement 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#18868
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?