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.
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.
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.
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
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?
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.
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.
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.
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
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
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...