Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 14:13:35 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #4492] What is the process for maintaining the PG (PostgreSQL) branch #2859

New Issue
Closed
opened 2026-02-22 18:31:33 -05:00 by yindo · 3 comments
yindo commented 2026-02-22 18:31:33 -05:00
Owner
Copy Link
Copy Source

Originally created by @jstawski on GitHub (Oct 4, 2025).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4492

I believe that AnythingLLM is a great product not only for personal use, but for the enterprise as well. Hosting this solution with SQLite is not a scalable solution and as such the PostgreSQL branch and container are a great alternative and should be given lots of love :)

I have noticed that the container image for PostgreSQL is built from the PG branch, yet I also noticed there are differences in the prisma files (migrations, schema.prisma, and migration_lock.toml). I would like to understand the process on how the PG branch is synchronized and maintained.

Thanks for all the hard work.

Originally created by @jstawski on GitHub (Oct 4, 2025). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/4492 I believe that AnythingLLM is a great product not only for personal use, but for the enterprise as well. Hosting this solution with SQLite is not a scalable solution and as such the PostgreSQL branch and container are a great alternative and should be given lots of love :) I have noticed that the container image for PostgreSQL is built from the `PG` branch, yet I also noticed there are differences in the prisma files (migrations, schema.prisma, and migration_lock.toml). I would like to understand the process on how the `PG` branch is synchronized and maintained. Thanks for all the hard work.
yindo closed this issue 2026-02-22 18:31:33 -05:00
yindo commented 2026-02-22 18:31:33 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Oct 5, 2025):

https://docs.anythingllm.com/installation-docker/available-images#pg

Deployment Frequency: On new releases

This is at least currently how we do release for the pg tag. It does need some more work to ensure it is released properly since there is a minor code diff to support the change in the schema. It would do well for us to additionally tag it as well so something like pg-185 for pg v1.8.5

@timothycarambat commented on GitHub (Oct 5, 2025): https://docs.anythingllm.com/installation-docker/available-images#pg > Deployment Frequency: On new releases This is at least currently how we do release for the `pg` tag. It does need some more work to ensure it is released properly since there is a _minor_ code diff to support the change in the schema. It would do well for us to additionally tag it as well so something like `pg-185` for `pg` `v1.8.5`
yindo commented 2026-02-22 18:31:34 -05:00
Author
Owner
Copy Link
Copy Source

@jstawski commented on GitHub (Oct 6, 2025):

@timothycarambat I would like to bring the topic of the pg branch to the forefront. Unless i'm missing something, having these differences in the branches sounds like it makes the release a little too manual and prone to error.

May I ask why the difference in the migrations folder? Couldn't the database be built from the same migration scripts as the master branch? Furthermore, can't we change the pg docker action to modify schema.prisma, and migration_lock.toml at run time? Doing this will allow us to keep a single branch and simplify the release. Am I missing something?

@jstawski commented on GitHub (Oct 6, 2025): @timothycarambat I would like to bring the topic of the pg branch to the forefront. Unless i'm missing something, having these differences in the branches sounds like it makes the release a little too manual and prone to error. May I ask why the difference in the migrations folder? Couldn't the database be built from the same migration scripts as the master branch? Furthermore, can't we change the pg docker action to modify `schema.prisma`, and `migration_lock.toml` at run time? Doing this will allow us to keep a single branch and simplify the release. Am I missing something?
yindo commented 2026-02-22 18:31:34 -05:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Oct 7, 2025):

No, because the prisma:migrate command generates totally different migration files than SQLite migration files since the two databases have two different primitives.

Example for workspace_documents table

they might not have the same columns, but just in general looking at the types

# sqlite
-- CreateTable
CREATE TABLE "workspace_documents" (
    "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    "docId" TEXT NOT NULL,
    "filename" TEXT NOT NULL,
    "docpath" TEXT NOT NULL,
    "workspaceId" INTEGER NOT NULL,
    "metadata" TEXT,
    "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "lastUpdatedAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT "workspace_documents_workspaceId_fkey" FOREIGN KEY ("workspaceId") REFERENCES "workspaces" ("id") ON DELETE RESTRICT ON UPDATE CASCADE
);

# postgres
-- CreateTable
CREATE TABLE "workspace_documents" (
    "id" SERIAL NOT NULL,
    "docId" TEXT NOT NULL,
    "filename" TEXT NOT NULL,
    "docpath" TEXT NOT NULL,
    "workspaceId" INTEGER NOT NULL,
    "metadata" TEXT,
    "pinned" BOOLEAN DEFAULT false,
    "watched" BOOLEAN DEFAULT false,
    "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
    "lastUpdatedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,

    CONSTRAINT "workspace_documents_pkey" PRIMARY KEY ("id")
);

They are not compatible so pg must be on a different branch as to keep conflicts to migrations to always conform to PG types.

You cannot have both migrations present in the master branch, and we will not be migrating the master branch DB to postgres. The pg image is to allow those who want to, to be able to use PG as their primary DB. Its just a convienence for that segment of users.

@timothycarambat commented on GitHub (Oct 7, 2025): No, because the `prisma:migrate` command generates totally different migration files than SQLite migration files since the two databases have two different primitives. Example for `workspace_documents` table _they might not have the same columns, but just in general looking at the types_ ```sql # sqlite -- CreateTable CREATE TABLE "workspace_documents" ( "id" INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT, "docId" TEXT NOT NULL, "filename" TEXT NOT NULL, "docpath" TEXT NOT NULL, "workspaceId" INTEGER NOT NULL, "metadata" TEXT, "createdAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, "lastUpdatedAt" DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT "workspace_documents_workspaceId_fkey" FOREIGN KEY ("workspaceId") REFERENCES "workspaces" ("id") ON DELETE RESTRICT ON UPDATE CASCADE ); ``` ```sql # postgres -- CreateTable CREATE TABLE "workspace_documents" ( "id" SERIAL NOT NULL, "docId" TEXT NOT NULL, "filename" TEXT NOT NULL, "docpath" TEXT NOT NULL, "workspaceId" INTEGER NOT NULL, "metadata" TEXT, "pinned" BOOLEAN DEFAULT false, "watched" BOOLEAN DEFAULT false, "createdAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, "lastUpdatedAt" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP, CONSTRAINT "workspace_documents_pkey" PRIMARY KEY ("id") ); ``` They are not compatible so `pg` must be on a different branch as to keep conflicts to migrations to always conform to PG types. You cannot have both migrations present in the `master` branch, and we will not be migrating the `master` branch DB to `postgres`. The `pg` image is to allow those who want to, to be able to use PG as their primary DB. Its just a convienence for that segment of users.
yindo changed title from What is the process for maintaining the PG (PostgreSQL) branch to [GH-ISSUE #4492] What is the process for maintaining the PG (PostgreSQL) branch 2026-06-05 14:48:56 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#2859
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?