Golang code structuring

Is it worth to group methods in structs:
For example:

type UserManager struct {
    DB *sql.DB
}

func (m UserManager) Insert (u User) error {...}
func (m UserManager) Delete (u User) error {...}
...

Or is it simpler support just separate functions.

func InsertUser (u User, db *sql.DB) error {...}

While second approach looks simpler at first, in future this way, there may be to many functions in package. Should I make separate package for every domain aggregate? In examples, I've seen so far, there is just model package.
I've been working mainly with OO languages so need some advice for go best practices here.

Your second suggestion is not good go code! Why? Because in the best case a function should take interfaces as an input.

So a InsertUserfunction should look something like that and it would combine your first with your second suggestion:

type Inserter interface {
   Insert(User)error
}
func InsertUser(i Inserter) error {...}

In that case testing of your function is easy, because you can easy mock the inserter.

Either, or neither - it really doesn't matter in my opinion because the idiomatic approach would be to organize these concepts using interfaces:

package user

type User ...

type Inserter interface { Insert(User) error }
type Deleter interface { Delete(User) error }
type Manager interface { Inserter, Deleter } // bloated interface

User in this case is probably a concrete row type like in your example, but one could make the case for making it too into an interface that doesn't mention those types.

If you write functions that reference these interfaces, then you can quickly glue together using embedding & promoted fields.

In your case it's obvious that sticking to the first implementation style is much simpler:

type userManager struct { ... }
func (userManager) Insert(u User) error { ... }
func (userManager) Delete(u User) error { ... }

userManager is a private type, so it can be changed without concern, as long as it keeps satisfying the public interfaces.

Keeping the interfaces decoupled from the implementation makes it much easier to make them narrow, so instead of just having a "user manager" or something, you can find out which interfaces you really need for the tasks. Incidentally, this approach has the nice property that it fits well with the object capability model, which helps to simplify things like role based access control.