#preexisting better-auth setup

13 messages · Page 1 of 1 (latest)

flat bronzeBOT
#

Hi @dense cloud. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:

#

Migrating from Postgres to Convex with Better Auth and Hono

Caveats to Migrating from Postgres to Convex:

  • Data Migration: You can migrate your data from Postgres to Convex using tools like streaming imports or by exporting your data to a format Convex supports (e.g., JSONL) and importing it with the Convex CLI. You'll need to define your Convex schema, and there are guides and even dashboard tools to help generate this schema based on your imported data. Relationships (foreign keys) in Postgres will need to be mapped to Convex's ID system, which may require writing migration scripts to update references after import. See the detailed migration steps and code examples here: Migrating data from Postgres to Convex.

  • Schema Differences: Convex schemas are defined in code and validated at runtime. You’ll need to translate your Postgres schema to Convex’s schema system, and update your application logic to use Convex’s query/mutation model instead of SQL.

  • Gradual User Migration: If you’re using Better Auth and have users in your Postgres DB, you can implement a gradual migration strategy. As users log in, you can check if they exist in Convex and migrate them on-the-fly in your onCreateUser hook. Note: migrating password hashes is not supported due to differences in hashing algorithms, so this approach works best for social logins or non-password-based auth flows. See: Migrating Existing Users.

#

Can You Stay on Postgres and Use Convex as Part of Your Backend?

  • Yes, you can use Convex alongside Postgres during a migration period. A common approach is to move your read path to Convex first (for reactivity and global state), while still writing to Postgres for legacy systems. You can use Convex Actions to push updates to Postgres, and later switch to Convex Mutations when you’re ready to fully migrate. However, Convex does not natively sync with Postgres—you’ll need to manage data consistency yourself during this hybrid phase. See the discussion here: Migrating to Convex from RDMS/SQL.

How Does Convex Work with Hono?

  • Convex can be integrated with Hono for HTTP routing. The convex-helpers package provides adapters to use Hono as your HTTP router in Convex, allowing you to define dynamic routes, use middleware (like CORS), and handle requests in a familiar way. You can mount Better Auth endpoints and your own API routes using Hono, and there are examples of how to combine Hono with Convex’s built-in HTTP router if you need both. See: Convex Hono Integration Guide and Stack article on Hono with Convex.

Summary:

  • Migrating from Postgres to Convex is supported, but requires schema translation and careful handling of relationships and user data.
  • You can run Convex and Postgres side-by-side during migration, but must manage data flow and consistency.
  • Convex works well with Hono via the convex-helpers package, supporting dynamic routes and middleware.
#

If you have specific requirements (e.g., complex queries, large data volumes, or custom auth flows), you may need to adapt your architecture or write custom migration scripts. The knowledge sources do not mention any direct, automatic sync between Convex and Postgres, so a hybrid approach is manual but feasible.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@dense cloud Kapa.ai is still learning and improving, please let me know how I did by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

If you are migrating from Better Auth on Postgres to Convex using Convex’s Postgres support (i.e., self-hosted Convex with a Postgres backend), here are the key points and caveats based on the knowledge sources:

1. Migrating from Better Auth on Postgres to Convex (Postgres-backed)

  • Convex’s Postgres Support: Convex can be self-hosted and configured to use Postgres as its underlying database. This means your data will reside in Postgres, but you will interact with it through Convex’s API and schema system, not directly via SQL. You must define your schema in Convex code, and Convex manages the data access patterns and indexing for you. You cannot use raw SQL or your existing Postgres schema directly—Convex expects you to use its own schema and access patterns, even if the data is stored in Postgres.
    See: Self-hosting Convex with Postgres

  • Better Auth Integration: The Better Auth Convex component expects to use Convex as the database adapter. If you migrate to Convex (even with a Postgres backend), you will need to adapt your user management to Convex’s schema and API. Password hashes and other sensitive fields may not be directly portable due to differences in how they are stored and validated.
    See: Migrating Existing Users

#
  • Caveats:
    • You cannot use your existing Postgres schema and expect Convex to “just work” with it. You must migrate your data and relationships to Convex’s schema system.
    • Any custom SQL queries or triggers you had in Postgres will not be available in Convex.
    • If you use email/password auth, you cannot migrate password hashes directly due to differences in hashing and storage.
    • You will need to update your application logic to use Convex’s query/mutation model.

2. Using Postgres as Auth Backend and Convex as an Additional Layer

  • Hybrid Approach: If you want to keep using Postgres (and Better Auth on Postgres) as your primary auth backend and add Convex as an additional layer for other parts of your app, this is technically possible, but there are caveats:
    • Convex is designed to be a full backend, including auth, and expects to manage its own user data.
    • There is no built-in way for Convex to “delegate” authentication to an external Postgres database or to use your existing Better Auth instance directly.
    • You could, in theory, use Convex’s custom auth integration to accept JWTs or tokens issued by your existing auth system, but you would need to implement the logic to verify and map those users inside Convex.
    • You would be responsible for keeping user data in sync between Postgres and Convex if you want to use Convex’s features that depend on user identity.

3. Summary

#
  • Migrating to Convex (even with Postgres as the backend) means adopting Convex’s schema and API, not just pointing Convex at your existing Postgres tables.
  • You cannot use Postgres as a “drop-in” auth backend for Convex without custom integration work.
  • If you want to keep using Postgres for auth and Convex for other features, you’ll need to handle user identity mapping and token verification yourself.

If you need a gradual migration, you can use a hybrid approach for a while, but you’ll need to manage the complexity of syncing user data and authentication state between the two systems. There is no out-of-the-box support for using Postgres as the auth backend while using Convex for other data.

If you need more details on a specific migration path or integration, let me know!

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@dense cloud Kapa.ai is still learning and improving, please let me know how I did by reacting below.

#

Let me check the knowledge base for you again. One moment! :books:

#

Convex does not provide built-in tenant-level data isolation like separate databases or physical separation per tenant (as you might achieve with Cloudflare Durable Objects per tenant). Instead, Convex is designed to support multi-tenancy through application-level permissions and authorization logic.

You can implement tenant isolation by:

  • Storing a tenantId field on every document.
  • Enforcing, in every query and mutation, that users can only access data belonging to their tenant. This is typically done by checking the user's identity and tenant association at the start of each function, and filtering or validating all data access accordingly.

Convex encourages this approach: "Convex allows developers to write arbitrary Javascript, which runs on the server within a transaction, that can check authorization. If you want to enforce an authorization rule, you can define it in code and check it whenever you want" (Row Level Security). This means you can implement row-level security (RLS) patterns to ensure users only access data for their tenant.

However, this is not physical isolation—all tenant data resides in the same Convex deployment/database, and isolation is enforced by your code. This is a common pattern in SaaS applications, but it does mean that a bug in your authorization logic could potentially allow cross-tenant data access. Convex does not currently offer a built-in, foolproof tenant isolation mechanism beyond what you implement in your functions (Authorization).

If you require strict, physical isolation (e.g., regulatory requirements), you would need to run a separate Convex deployment per tenant, which is possible but increases operational complexity.

#

Summary:
You can achieve tenant isolation in Convex via permissions and row-level security logic in your code, but this is not the same as the physical isolation you get with separate Durable Objects per tenant. Be diligent in your authorization checks to ensure proper isolation.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: