-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: use _supabase database for internals #2707
chore: use _supabase database for internals #2707
Conversation
This is to avoid overloading our user postgres database with every new addition to _analytics or _realtime
Pull Request Test Coverage Report for Build 11074018500Details
💛 - Coveralls |
internal/start/start.go
Outdated
@@ -750,7 +750,7 @@ EOF | |||
fmt.Sprintf("DB_PORT=%d", dbConfig.Port), | |||
"DB_USER=supabase_admin", | |||
"DB_PASSWORD=" + dbConfig.Password, | |||
"DB_NAME=" + dbConfig.Database, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
realtime
schema should be initialised inside the postgres database. We probably need to check with @filipecabaco if there's additional config for separating the control plane database.
psql (16.3, server 15.6)
Type "help" for help.
_supabase=> \dn
List of schemas
Name | Owner
------------+-------------------
_analytics | postgres
_realtime | postgres
_supavisor | postgres
public | pg_database_owner
realtime | postgres
(5 rows)
_supabase=> \dt realtime.*
List of relations
Schema | Name | Type | Owner
----------+-------------------+-------+-------------------------
realtime | messages | table | supabase_realtime_admin
realtime | schema_migrations | table | supabase_admin
realtime | subscription | table | supabase_admin
(3 rows)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like this one is good to go. We can deal with realtime later after gaining more clarity.
Co-authored-by: Han Qiao <[email protected]>
Following: supabase/cli#2707 BREAKING CHANGES: When migrating from an older version you will need to manually create the new internal _supabase database and analytics schema the same way the and do. Via:
* chore: move _analytics to a distinct database Following: supabase/cli#2707 BREAKING CHANGES: When migrating from an older version you will need to manually create the new internal _supabase database and analytics schema the same way the and do. Via: * feat: add supavisor to the self-hosted stack * chore(docs): add docs about supavisor * chore: fix reviewdog warning * chore: fix typo * chore: apply pr comments
* chore: move _analytics to a distinct database Following: supabase/cli#2707 BREAKING CHANGES: When migrating from an older version you will need to manually create the new internal _supabase database and analytics schema the same way the and do. Via: * feat: add supavisor to the self-hosted stack * chore(docs): add docs about supavisor * chore: fix reviewdog warning * chore: fix typo * chore: apply pr comments
This is to avoid overloading our user postgres database with every new addition to _analytics or _realtime
What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
What is the current behavior?
Please link any relevant issues here.
What is the new behavior?
Feel free to include screenshots if it includes visual changes.
Additional context
Add any other context or screenshots.