5 ms·

"Grow for years" only really works if your SaaS also exists in years. I can't imagine deciding to run a production DB with a custom RLS thing going on without b

"Grow for years" only really works if your SaaS also exists in years. I can't imagine deciding to run a production DB with a custom RLS thing going on without being able to directly port that off-provider in a worst case scenario. Supabase sort of gets around this by being open source, but even then depending on their custom setup gives me a little anxiety. Not sure about other managed/"serverless" Postgres.

infra_dev 3y ago
Nile CEO here. Nile will promise to make the experience of moving out of Nile really easy. This is one our core product principles. We want users to stay for the value we provide. Nile user permissions are optional. You can decide to use any third-party provider for it. We are in the design phase for permissions at this point. We would love to get your feedback to understand more about your concerns https://github.com/orgs/niledatabase/discussions/159 https://github.com/orgs/niledatabase/discussions/159
- infra_dev 3y ago
  I do also want to mention that we don't fork Postgres. We have built tooling around Postgres using extensions and gateway layers on top of it.
  - endigma 3y ago
    This doesn't necessarily mean that any user could pick up and switch to a different PG instance, as such a young provider maybe look at having some docs for migrating off-platform as a sort of assurance. Maintaining those docs might also help you prevent adding or changing things that would introduce lock-in, it should be a consideration for every feature or API change.
    - infra_dev 3y ago
      Agree. We will prioritize how to migrate from Nile. At the Postgres level we don't want any lock-ins. We would have APIs that simply SaaS workflows that users may choose to use.
- endigma 3y ago
  That's good to hear, the last thing we need in software is more lock-in.
kiwicopple 3y ago
It’s worth mentioning that portability is one of our core Principles at Supabase too: https://supabase.com/docs/guides/getting-started/architecture#everything-is-portable https://supabase.com/docs/guides/getting-started/architectur... This is why we don’t run a fork of Postgres, and we lean heavily into extensions rather than customizations. As the docs mention: this forces us compete on experience. (Speaking here to your point about supabase, not to detract from Nile, which looks very cool)
- endigma 3y ago
  I use Supabase at work for this reason, just not sure I'm _completely_ prepared to pick up and move to a non-Supabase PG if I really had to, which is a little unsettling for long term reliability. This is probably a me problem, you guys are doing great work on avoiding lock-in.
  - kiwicopple 3y ago
    I recommend complimenting the supabase tooling with “external” tooling - pgadmin, direct Postgres libs, etc. Even if you don’t migrate (which we hope you never do) you’ll definitely become more seasoned Postgres developer and you should find that we’re not doing anything too “magical”. Everything you learn with supabase should be transferable
- infra_dev 3y ago
  Hey kiwicopple, big virtual hi. I am a fan of your work.
  - kiwicopple 3y ago
    congrats on the launch!

infra_dev 3y ago

Nile CEO here. Nile will promise to make the experience of moving out of Nile really easy. This is one our core product principles. We want users to stay for the value we provide. Nile user permissions are optional. You can decide to use any third-party provider for it. We are in the design phase for permissions at this point. We would love to get your feedback to understand more about your concerns https://github.com/orgs/niledatabase/discussions/159 https://github.com/orgs/niledatabase/discussions/159

infra_dev 3y ago
I do also want to mention that we don't fork Postgres. We have built tooling around Postgres using extensions and gateway layers on top of it.
- endigma 3y ago
  This doesn't necessarily mean that any user could pick up and switch to a different PG instance, as such a young provider maybe look at having some docs for migrating off-platform as a sort of assurance. Maintaining those docs might also help you prevent adding or changing things that would introduce lock-in, it should be a consideration for every feature or API change.
  - infra_dev 3y ago
    Agree. We will prioritize how to migrate from Nile. At the Postgres level we don't want any lock-ins. We would have APIs that simply SaaS workflows that users may choose to use.
endigma 3y ago
That's good to hear, the last thing we need in software is more lock-in.

kiwicopple 3y ago

It’s worth mentioning that portability is one of our core Principles at Supabase too: https://supabase.com/docs/guides/getting-started/architecture#everything-is-portable https://supabase.com/docs/guides/getting-started/architectur... This is why we don’t run a fork of Postgres, and we lean heavily into extensions rather than customizations. As the docs mention: this forces us compete on experience. (Speaking here to your point about supabase, not to detract from Nile, which looks very cool)

endigma 3y ago
I use Supabase at work for this reason, just not sure I'm _completely_ prepared to pick up and move to a non-Supabase PG if I really had to, which is a little unsettling for long term reliability. This is probably a me problem, you guys are doing great work on avoiding lock-in.
- kiwicopple 3y ago
  I recommend complimenting the supabase tooling with “external” tooling - pgadmin, direct Postgres libs, etc. Even if you don’t migrate (which we hope you never do) you’ll definitely become more seasoned Postgres developer and you should find that we’re not doing anything too “magical”. Everything you learn with supabase should be transferable
infra_dev 3y ago
Hey kiwicopple, big virtual hi. I am a fan of your work.
- kiwicopple 3y ago
  congrats on the launch!