Hacker News Reader

Comment by endigma | Hacker News Reader

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

View on HN

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

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.

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.

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.

That's good to hear, the last thing we need in software is more lock-in.

It’s worth mentioning that portability is one of our core Principles at Supabase too:

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)

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.

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

Hey kiwicopple, big virtual hi. I am a fan of your work.

congrats on the launch!

Reply on news.ycombinator.com