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.
UHey! Do you mind sharing more details about your use case?
AThe 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.
AOf 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.
UYea that's tricky to build 
I'm curious, why would you like to have a Neon project for every tenant?
I'm curious, why would you like to have a Neon project for every tenant?
AIf 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.
AJust to make sure we're on the same page – I mean this type of project.
UWhat I meant was do you have specific requirements that make you want to follow this architecture?
AWhat better solution do you suggest?
UHmm, well it depends on what you're building. Do you mind sharing more details?
AI 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
UYou 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
AI 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?
UNot 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 
UFeel free to reach out if you have any questions or run into any issues
AIt 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.
MThat‘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.
AHi, any progress here? 
A@Mahmoud @Daniel
Aits show stopper here for us and many multi-db tenant apps
IHi! 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.
AI 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
https://x.com/nikitabase/status/1870215286114472213?s=46&t=sxZY27o79HFvg_XKO6MLMQ
@PatrikGmitter @neondatabase We now have a migration assistant. It will cover this scenario soon
X
•12/20/24, 9:10 PM
INot 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
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
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...
AThank 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!
IThey are already looking at it
