Feature request: transfer database between projects
It would be great if there were an option in the administration panel or via the API to transfer a database from one project to another.
20 Replies
fascinating-indigo•9mo ago
Hey! Do you mind sharing more details about your use case?
absent-sapphireOP•9mo ago
The reason is that we plan to place multiple tenants (databases) under a single project as a cost-saving measure. If a tenant either A) consumes excessive resources (noisy neighbor) or B) upgrades to a more expensive plan, it should be possible to easily move them to a separate project, where they would have access to more resources.
Of course, it is possible to do it using dump&import, but having the option to move it out of the box with one click or via API would be very convenient.
fascinating-indigo•9mo ago
Yea that's tricky to build 😅
I'm curious, why would you like to have a Neon project for every tenant?
absent-sapphireOP•9mo ago
If I'm not mistaken, the Neon documentation recommends creating a project for each tenant in several places. However, it doesn't necessarily have to be 1 project = 1 tenant. But in case, for example, there are three demanding/noisy tenants side by side in one project, it would be possible to distribute each of them into different projects. This is just an idea; if it's too complicated to implement, don't worry about it—it's not a blocker.
absent-sapphireOP•9mo ago
Just to make sure we're on the same page – I mean this type of project.
fascinating-indigo•9mo ago
What I meant was do you have specific requirements that make you want to follow this architecture?
absent-sapphireOP•9mo ago
What better solution do you suggest?
fascinating-indigo•9mo ago
Hmm, well it depends on what you're building. Do you mind sharing more details?
absent-sapphireOP•9mo ago
I probably won't go into detail publicly, as the project is in a very early stage of development. I am tentatively considering the following distribution:
- Free plan: max 250 tenants (databases) per project
- Low paid plan: max 100 tenants (databases) per project
- High paid plan: max 25 tenants (databases) per project
This is because paid plans typically have higher traffic, resulting in more connections to the database. However, it might turn out that even 250+ tenants per project can be handled without issues. It's hard to say in advance... I'm exploring the options.
- Low paid plan: max 100 tenants (databases) per project
- High paid plan: max 25 tenants (databases) per project
This is because paid plans typically have higher traffic, resulting in more connections to the database. However, it might turn out that even 250+ tenants per project can be handled without issues. It's hard to say in advance... I'm exploring the options.
fascinating-indigo•9mo ago
You could have all tenants in the same Neon project in a single database. You can then achieve data isolation using row level security and filtering by the tenant ID
absent-sapphireOP•9mo ago
I understand, but we prefer the option of a multi-tenant database rather than a single-tenant database. This is also one of the reasons why we are seriously considering using Neon DB; otherwise, we would likely opt for a managed database on AWS. Why do you ask? Is there a specific reason that should discourage us from this choice?
fascinating-indigo•9mo ago
Not at all, just want to make sure I'm guiding you in the right direction. Thank you for taking the time to share more details 😄
Feel free to reach out if you have any questions or run into any issues
absent-sapphireOP•9mo ago
It would also be beneficial in cases where I need to migrate databases from Project A (older version of Postgres) to Project B (with a newer version of Postgres). With a larger number of projects/tenants, manually migrating databases to a new project with a higher Postgres version can become tedious.
absent-sapphire•9mo ago
That‘s a good idea! I think it would be much more convenient to have these functions than manually backing up and restoring when changing the region of the database or upgrading the Postgres version.
absent-sapphireOP•4mo ago
Hi, any progress here? 🙏
@Mahmoud @Daniel
its show stopper here for us and many multi-db tenant apps
rare-sapphire•4mo ago
Hi! I was about to post something similar a feature where you can replicate the tables and schemas in development onto prod. It would be so much easier so you dont have to re-alter the tables whenever changes are made.
absent-sapphireOP•4mo ago
I hope you don’t mind me following up—I just wanted to kindly ask if I can expect a response. I saw on X some time ago that this was being worked on, so I’m wondering if it’s something I can count on or not. Apologies if I’m putting any pressure on you, that’s not my intention. Thank you for your time!
https://x.com/nikitabase/status/1870215286114472213?s=46&t=sxZY27o79HFvg_XKO6MLMQ
Nikita | Scaling Postgres (@nikitabase) on X
@PatrikGmitter @neondatabase We now have a migration assistant. It will cover this scenario soon
X
automatic-azure•4mo ago
Not a problem. You can already do this using our Import Data Assistant: https://neon.tech/docs/import/import-data-assistant
Simply copy the database connection string from your existing Neon project, go to your other Neon project, open the Import Data Assistant, and import. Your database will be migrated to a new branch in your eixting project.
Currently, the assistant is primarily intended for migrating data from another Postgres instance to Neon, but it works just as well for Neon project > to Neon project database migrations.
There are things we can improve on for Neon to Neon migrations — and that's what we're looking at now, but within the limits deifned in the doc I linked to above, you can do it today 🙂
Neon
Import Data Assistant - Neon Docs
When you're ready to move your data to Neon, our Import Data Assistant can help you automatically copy your existing database to Neon. You only need to provide a connection string to get started. Ways...
absent-sapphireOP•4mo ago
Thank you, I’ll give it a try. If you happen to implement improvements or loosen some of the limitations in the future, that would be fantastic!
automatic-azure•4mo ago
They are already looking at it 🙂